Issue Number | 3934 |
---|---|
Summary | Database query error while validating a summary module |
Created | 2015-06-23 14:46:16 |
Issue Type | Bug |
Submitted By | Osei-Poku, William (NIH/NCI) [C] |
Assigned To | Kline, Bob (NIH/NCI) [C] |
Status | Closed |
Resolved | 2015-11-17 14:12:16 |
Resolution | Fixed |
Path | /home/bkline/backups/jira/ocecdr/issue.163875 |
When saving and validating the Risk Factors for Cervical Cancer summary module (CDR753255), a SQL Error code is displayed indicating that there was a failure executing database query. The message is attached. This happened at about 10:00 AM today and I was able to reproduce the error at about 12:32 PM by attempting to save and validate the document.
Wow, was this fun to track down without the DEV environment. :-)
Back in the spring of last year Alan created a custom schema validation rule for OCECDR-3723. We debated for that ticket whether to handle the validation with a link validation rule or a schema validation rule. Alan's conclusion was that the link validation rule would be more elegant, but the custom schema validation would be easier to implement, and we decided to go that route.
The rule that he came up with assumes that there will be a valid CDR ID in the cdr:ref attribute of the PatientVersionOf element (not a wild assumption, since that's required elsewhere by the schema). However, since we're executing the logic of the new custom rule in the context of validation the document, we can't assume that the document is valid. In this case, your document is missing the cdr:ref attribute for the PatientVersionOf element altogether. If you want, we can keep this open (possibly assigned to Alan) to enhance the rule to guard against this condition, but you can avoid the DB query error by supplying the missing attribute with a valid CDR ID.
If this happens one more time, perhaps a year from now when we've forgotten the cause, it could take more time to track down than it would take to make the fix. So I suggest we create an issue and make the fix.
Note for the long-term fix:
Test needs to start out something like {code:xml}
<assert test="string(number(substring(@cdr:ref))) != 'NaN' and
..."/>
I've put this in the Darwin queue.
Turns out that our custom rule validation engine doesn't apply short-circuit logic, so I had to rewrite the rule like this:
<!--
Verify Patient Summary language matches linked to HP Summary
-->
rule context = 'PatientVersionOf'>
<assert test = '/Summary/SummaryMetaData/SummaryLanguage =
< document(concat("cdrutil:/sql-query/
SELECT value
FROM query_term
WHERE path = '/Summary/SummaryMetaData/SummaryLanguage'
AND doc_id = ?~",
string(number(concat("0", substring(@cdr:ref,4))))))/SqlResult/row/col'
assert>
>SummaryLanguage in Patient and linked-to HP Summary must match</rule> </
..., prefixing what we get from the substring() call (which might be an empty string) with "0" (in case it is).
Modified on DEV.
Bob, I am a little unclear about how to test this issue. I added a PatientVersionOf element to a summary module and replaced the CDR ID in the attribute inspector with a bogus CDR ID, and it was invalid with the appropriate messages. Is that it? This seems strange since I am selecting the document to be linked and the CDR ID is populated automatically...
That's about all you can do for testing, I think.
OK, thanks. I'm considering this verified on QA, then.
Verified on PROD. Thanks!
File Name | Posted | User |
---|---|---|
SQL Error_one.JPG | 2015-06-23 14:46:16 | Osei-Poku, William (NIH/NCI) [C] |
SQL Error.JPG | 2015-06-23 14:46:16 | Osei-Poku, William (NIH/NCI) [C] |
Elapsed: 0:00:00.001371