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
Copy file name to clipboardExpand all lines: docs/dqx/docs/guide/quality_checks_definition.mdx
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -342,7 +342,7 @@ Checks defined using declarative syntax must contain the following fields:
342
342
-`arguments`: keyword arguments passed to the check function. Every parameter without a default in the function’s Python signature must appear here.
343
343
-`for_each_column`: (optional) list of column names or expressions for which the same check should be applied. When saving with `DQEngine.save_checks` to Delta or Lakebase tables, DQX stores such checks in compact format (one row per check, `for_each_column` preserved).
344
344
- (optional) `name`: name of the check: autogenerated if not provided.
345
-
- (optional) `filter`: spark expression to filter the rows for which the check is applied (e.g. `"business_unit = 'Finance'"`). The check function will run only on the rows matching the filter condition. The condition can reference any column of the validated dataset, not only the one where you apply the check function. When using dataset-level checks, the filter condition is pushed down as `row_filter` to the check function and applied before aggregation, ensuring that the check operates only on the relevant subset of rows rather than on the aggregated results.
345
+
- (optional) `filter`: spark expression to filter the rows for which the check is applied (e.g. `"business_unit = 'Finance'"`). The check function will run only on the rows matching the filter condition. The condition can reference any column of the validated dataset, not only the one where you apply the check function. When using dataset-level checks, the filter condition is pushed down as `row_filter` to the check function and applied before aggregation, ensuring that the check operates only on the relevant subset of rows rather than on the aggregated results. Subqueries are allowed (e.g. `"customer_id IN (SELECT customer_id FROM main.ref.active_customers)"`), so you can scope a check using a reference table. A filter containing a destructive SQL keyword (e.g. `DELETE`, `DROP`, `INSERT`, `UPDATE`, `TRUNCATE`) is treated as invalid: that check is skipped (reported with `skipped = true` and a message identifying the unsafe filter) while the remaining checks still run.
346
346
- (optional) `user_metadata`: key-value pairs added to the row-level warnings and errors
347
347
348
348
## YAML format (declarative approach)
@@ -699,7 +699,7 @@ The table used to store checks has the following structure. You can use `for_eac
699
699
| └─ `function`|`string`| Name of the DQX check function to apply. |
700
700
| └─ `for_each_column`|`array<string>`| (Optional) List of columns for which the same check applies. Stored in compact format (one row per check). Manual tables can use compact or expanded (individual rules instead of for_each_column) format. |
701
701
| └─ `arguments`|`map<string, string>`| Keyword arguments for the check function. All parameters without a default must be present (or supplied via `for_each_column` for `column` / `columns`). |
702
-
|`filter`|`string`| (Optional) Spark SQL expression to filter rows to which the check is applied, e.g. `"business_unit = 'Finance'"`. The check function will run only on the rows matching the filter condition. The condition can reference any column of the validated dataset, not only the one where you apply the check function. When using dataset-level checks, the filter condition is pushed down as `row_filter` to the check function and applied before aggregation, ensuring that the check operates only on the relevant subset of rows rather than on the aggregated results. |
702
+
|`filter`|`string`| (Optional) Spark SQL expression to filter rows to which the check is applied, e.g. `"business_unit = 'Finance'"`. The check function will run only on the rows matching the filter condition. The condition can reference any column of the validated dataset, not only the one where you apply the check function. When using dataset-level checks, the filter condition is pushed down as `row_filter` to the check function and applied before aggregation, ensuring that the check operates only on the relevant subset of rows rather than on the aggregated results. Subqueries are allowed (e.g. `"customer_id IN (SELECT customer_id FROM main.ref.active_customers)"`), so you can scope a check using a reference table. A filter containing a destructive SQL keyword (e.g. `DELETE`, `DROP`, `INSERT`, `UPDATE`, `TRUNCATE`) is treated as invalid: that check is skipped (reported with `skipped = true` and a message identifying the unsafe filter) while the remaining checks still run.|
703
703
|`run_config_name`|`string`| Name of the run config name. Could be any string such as input table or job name (use "default" if not provided). Useful for selecting applicable checks. |
704
704
|`user_metadata`|`map<string, string>`| (Optional) Custom metadata to add to any row-level warnings or errors generated by the check. |
705
705
|`created_at`|`timestamp`| Current local date and time in UTC when the rule set was saved. |
0 commit comments