You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I remember correctly, there was previously a parsing of the error message to determine which status to use - failed or isError.
If the error message was about a missing table or field, then failed status was used, otherwise isError status was used.
But this was not interpreted for all SQL dialects, and the default behavior for such cases was simply to set failed = 1 for any error.
The text was updated successfully, but these errors were encountered:
I agree this is unideal behavior and that we should refactor the way that cdmTable and cdmField failures/errors are handled. I think we need to add special handling for these types of checks (I would also like to add the option to query the information schema for users who have read access - this is really the best way to determine DDL conformance).
I believe that special error handling in case of missing table or field should be applied to other checks as well.
For example: suppose a field is missing, the cdmField check will fail and return “failed” status, but when we try to run any other check for that field, it will return an error, and since the “isError” status has a higher priority than the “NA” status, the check will be marked with “isError” status instead of “NA” status.
Good flag; agree this should also be changed. Ideally, checks that will be NA should not even run in the first place! We've been discussing a refactor of the end to end DQD workflow and will definitely consider this as part of that work.
It looks like if any check finishes with an error message, it will return isError = 1 instead of failed = 1:
DataQualityDashboard/R/evaluateThresholds.R
Line 154 in 98c825a
This behavior breaks the cdmTable check and the cdmField check - they will both return isError instead of failed in case of missing table or field.
It also breaks the NA status calculation:
DataQualityDashboard/R/calculateNotApplicableStatus.R
Line 91 in 98c825a
If I remember correctly, there was previously a parsing of the error message to determine which status to use - failed or isError.
If the error message was about a missing table or field, then failed status was used, otherwise isError status was used.
But this was not interpreted for all SQL dialects, and the default behavior for such cases was simply to set failed = 1 for any error.
The text was updated successfully, but these errors were encountered: