[CORE-203] Restore requirement to look at M_APPLIED_PATH when retrieving modifier info from the Ontology Cell Created: 04/Jan/16  Updated: 25/Jan/16  Resolved: 12/Jan/16

Status: Closed
Project: i2b2 Core Software
Component/s: Ontology Cell
Affects Version/s: 1.7.03, 1.7.04, 1.7.05, 1.7.06
Fix Version/s: 1.7.07

Type: Bug Priority: Major
Reporter: Janice Donahoe Assignee: Janice Donahoe
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0d
Time Spent: 0.75d
Original Estimate: Not Specified

Issue Links:
related to CORE-143 Do not require M_APPLIED_PATH when re... Closed
Rank: 0|i002k7:
i2b2 Feature/s:
i2b2 Sponsored Project/s:
i2b2 Core, i2b2 Web Client
i2b2 Related Project/s:
Affects Database/s:
All databases
Reproduction Notes: This can be reproduced in the i2b2 Testing and Demo environments.
Developer Notes: This change is to override a previous SHRINE fix. When the m_applied_path is valid (the i2b2 case) return the modifier that matches both fullname and m_applied_path. If that query returns zero (the SHRINE case where m_applied_path may not exist) return a list of modifiers that match the c_fullname. It is assumed that this second option occurs when the CRC does a getModifierInfo to obtain query parameters. In that case the CRC has no option but to pick the first returned modifier's query parameters.
Testing Notes: TEST STATUS: Completed


Test Date: 01/06/2016
Build Number:
Test Status: Completed (Passed Testing)

Clients Tested :
     i2b2 Web Client
     i2b2 Workbench

Environments Tested :
     Browsers: Not applicable for this test
     Databases: Not applicable for this test
     Client OS: Windows and Macintosh

Test Comments:
Tested with the latest i2b2 Server build and it appears to be working correctly. The Ontology cell is using the applied_path when determining the modifier. This has resulted in only one modifier being returned instead of thousands.

No issues were found.

In release 1.7.03, a change was made in the Ontology cell to no longer require the M_APPLIED_PATH when retrieving the modifier information and the associated concept. This change has introduced problems in the i2b2 Web Client, Workbench, and overall response time.

When the Ontology cell receives a getModifierInfo message it ignores the M_APPLIED_PATH; it only looks at the C_FULLNAME to determine what modifier(s) to return. Depending on how your modifiers are defined in the metadata table you could have hundreds of modifiers returned instead of the one that matches the M_APPLIED_PATH and C_FULLNAME. This can result in a large response message being returned to the i2b2 Web Client or Workbench. This in turn causes performance issues in regards to slow response times when a modifier is added to a panel in the Query Tool or edits are made to the Modifier Value constraints window.

In addition to performance issues, this change also introduced problems in both the Web Client and the Workbench.

1. In the Web Client, the wrong value constraints can be displayed in the Modifier Value Constraint window. This is because the client does not know which modifier in the list returned in the xml message is the correct one, so it takes the data from the first one.
2. In the Workbench, the value constraints that display in the Modifier Value Constraint window appear to be duplicated several times. Since the workbench doesn’t know which one is the right modifier, it is displaying the data for numerous modifiers.
3. Web Client queries cannot be re-run in the Workbench if the query has a modifier with a value constraint. The query will fail because the value constraint will be duplicated for each modifier.

The change made in 1.7.03 (CORE-143) was done to support SHRINE networks that did not have the modifiers in their SHRINE ontology mapped to the modifiers in the local site ontologies. The query would fail because the M_APPLIED_PATH that was sent from the SHRINE would be the one from the SHRINE ontology and therefore would not exist in any of the local ontologies. The solution at the time was to have the Ontology cell ignore the M_APPLIED_PATH.

In release 1.7.07 the Ontology cell will once again look at the M_APPLIED_PATH when determining the appropriate modifier information to return. The fix has been modified slightly; logic will now be added that will fix the i2b2 and support SHRINE Networks that do not have their modifiers mapped.

The following logic will be added to the fix:

-- If the Ontology Cell finds the M_APPLIED_PATH in the metadata table then only one modifier will be returned.

-- If the Ontology Cell does not find the M_APPLIED_PATH then it will ignore it and return all modifiers with the appropriate C_FULLNAME.

Comment by Janice Donahoe [ 25/Jan/16 ]
On 01/22/2016, the 1.7.07 Release was made available at the following locations.

 - zip files for release 1.7.07 are available on this site. This includes both the code and documentation.

 - source code has been tagged with v1.7.07.
Generated at Sun Apr 05 17:05:11 UTC 2020 using JIRA 7.6.3#76005-sha1:8a4e38d34af948780dbf52044e7aafb13a7cae58.