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: README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -867,7 +867,7 @@ While the rules defined in this package are considered best practices, we realiz
867
867
An example would be excluding all models with names matching with `stg_..._unioned` from `fct_multiple_sources_joined` as we might want to union 2 different tables representing the same data in some of our staging models and we don't want the test to fail for those models.
868
868
869
869
The package offers the ability to define a seed called `dbt_project_evaluator_exceptions.csv` to list those exceptions we don't want to be reported. This seed must contain the following columns:
870
-
- `fct_name`: the name of the fact table for which we want to define exceptions
870
+
- `fct_name`: the name of the fact table for which we want to define exceptions (Please note that it is not possible to exclude specific models for all the `coverage` tests, but there are variables available to configure those to the particular users' needs)
871
871
- `column_name`: the column name from `fct_name` we will be looking at to define exceptions
872
872
- `id_to_exclude`: the values (or `like` pattern) we want to exclude for `column_name`
873
873
- `comment`: a field where people can document why a given exception is legitimate
0 commit comments