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
Hello,
In reality, the Data Quality(DQ) SQL failure report is much more beyond the DQ SQL itself. Let me take a simple example to explain:
Table1 EMP(EMP_ID, ENAME, MGR_ID, EMP_START_DT, EMP_END_DT)
Table2 SALARY(EMP_ID, SALARY_NO, CHANGE_DT, BONUS)
DQ SQL: select count(1) from SALARY where BONUS > 100000;
If the count above is greater than 0, then the DQ Report email or Jira ticket should contain this report from multiple tables:
EMP_ID, BONUS, MGR_ID, MGR_ENAME, MGR_EMAIL, MGR_ADDRESS
How do we setup a report SQL that is different from its DQ SQL, does the Soda core engine support this functionality today?
The Report SQL will use the primary keys returned by the DQ SQL to go against the dependent tables to construct the data for the Report. Please advice.
The text was updated successfully, but these errors were encountered:
Hi! Do I get it correctly that you would want to have the ability to provide an SQL query to get the failed rows which is independent of the SQL Soda Core used to generate the metric?
Yes, that’s correct. Using the failed rows, we need an ability to generate a report containing more attributes from tables not used in the initial Soda core Data Quality SQL. Thank you!
Hello,
In reality, the Data Quality(DQ) SQL failure report is much more beyond the DQ SQL itself. Let me take a simple example to explain:
Table1 EMP(EMP_ID, ENAME, MGR_ID, EMP_START_DT, EMP_END_DT)
Table2 SALARY(EMP_ID, SALARY_NO, CHANGE_DT, BONUS)
DQ SQL: select count(1) from SALARY where BONUS > 100000;
If the count above is greater than 0, then the DQ Report email or Jira ticket should contain this report from multiple tables:
EMP_ID, BONUS, MGR_ID, MGR_ENAME, MGR_EMAIL, MGR_ADDRESS
How do we setup a report SQL that is different from its DQ SQL, does the Soda core engine support this functionality today?
The Report SQL will use the primary keys returned by the DQ SQL to go against the dependent tables to construct the data for the Report. Please advice.
The text was updated successfully, but these errors were encountered: