Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Adapter constraint support tables #3944

Merged
merged 8 commits into from
Aug 21, 2023
Merged

Adapter constraint support tables #3944

Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
e0c9f07
Adapter constraint support tables
matthewshaver Aug 17, 2023
deefb21
Apply suggestions from code review
matthewshaver Aug 17, 2023
517a8fb
Update model-contracts.md
matthewshaver Aug 17, 2023
93705f6
Updates based on feedback
matthewshaver Aug 21, 2023
39acfb6
Merge branch 'current' into contract-constraints
matthewshaver Aug 21, 2023
4c3f8ce
Update website/docs/docs/collaborate/govern/model-contracts.md
matthewshaver Aug 21, 2023
2b24edc
Apply suggestions from code review
matthewshaver Aug 21, 2023
17d98d7
Update website/docs/docs/collaborate/govern/model-contracts.md
matthewshaver Aug 21, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
85 changes: 85 additions & 0 deletions website/docs/docs/collaborate/govern/model-contracts.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -86,6 +86,91 @@ When building a model with a defined contract, dbt will do two things differentl
1. dbt will run a "preflight" check to ensure that the model's query will return a set of columns with names and data types matching the ones you have defined. This check is agnostic to the order of columns specified in your model (SQL) or YAML spec.
2. dbt will include the column names, data types, and constraints in the DDL statements it submits to the data platform, which will be enforced while building or updating the model's table.

## Platform constraint support

Select the adapter-specific tab for more information on [constraint](/reference/resource-properties/constraints) support across platforms. Constraints fall into three categories based on support and platform enforcement:

- **Supported and enforced** — The model won't build if it violates the constraint.
- **Supported and not enforced** — The platform supports specifying the type of constraint, but a model can still build even if building the model violates the constraint. This constraint exists for metadata purposes only. This is common for modern cloud data warehouses and less common for legacy databases.
- **Not supported and not enforced** — You can't specify the type of constraint for the platform.
Comment on lines +93 to +95
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice if the bolded descriptions were more readable. Right now, the last one feels too verbose and the middle one could be more precise.

Would the following in conjunction with the split columns be clear enough?

  • Enforced or Supported and enforced or Supported & enforced
  • Supported (but not enforced) or Supported but not enforced or Supported; not enforced
  • Not supported or Not supported (and not enforced)

#3944 (review) begins the original discussion about this.




<Tabs>

<TabItem value="Redshift" label="Redshift">

| Constraint type | Support | Platform enforcement |
|:----------------|:-------------|:------------------|
| not_null | ✅ Supported | ✅ Enforced |
| primary_key | ✅ Supported | ❌ Not enforced |
| foreign_key | ✅ Supported | ❌ Not enforced |
| unique | ✅ Supported | ❌ Not enforced |
| check | ❌ Not supported | ❌ Not enforced |

</TabItem>
<TabItem value="Snowflake" label="Snowflake">

| Constraint type | Support | Platform enforcement |
|:----------------|:-------------|:---------------------|
| not_null | ✅ Supported | ✅ Enforced |
| primary_key | ✅ Supported | ❌ Not enforced |
| foreign_key | ✅ Supported | ❌ Not enforced |
| unique | ✅ Supported | ❌ Not enforced |
| check | ❌ Not supported | ❌ Not enforced |

</TabItem>
<TabItem value="BigQuery" label="BigQuery">

| Constraint type | Support | Platform enforcement |
|:-----------------|:-------------|:---------------------|
| not_null | ✅ Supported | ✅ Enforced |
| primary_key | ✅ Supported | ✅ Enforced |
| foreign_key | ✅ Supported | ✅ Enforced |
| unique | ❌ Not supported | ❌ Not enforced |
| check | ❌ Not supported | ❌ Not enforced |

</TabItem>
<TabItem value="Postgres" label="Postgres">

| Constraint type | Support | Platform enforcement |
|:----------------|:-------------|:--------------------|
| not_null | ✅ Supported | ✅ Enforced |
| primary_key | ✅ Supported | ✅ Enforced |
| foreign_key | ✅ Supported | ✅ Enforced |
| unique | ✅ Supported | ✅ Enforced |
| check | ✅ Supported | ✅ Enforced |

</TabItem>
<TabItem value="Spark" label="Spark">

Currently, `not_null` and `check` constraints are supported and enforced only after a model builds. Because of this platform limitation, dbt considers these constraints `supported` but `not enforced`, which means they're not part of the "model contract" since these constraints can't be enforced at build time. This table will change as the features evolve.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like the identical Databricks copy below, this paragraph is confusing.

I'd suggest rewriting for more clarity, potentially like the following:

Currently, not_null and check constraints are applied only after a model builds. Because of this platform limitation, dbt considers these constraints supported but not enforced, which means they're not part of the "model contract" since these constraints can't be enforced at build time. This table will change as the features evolve.


| Constraint type | Support | Platform enforcement |
|:----------------|:------------|:---------------------|
| not_null | ✅ Supported | ❌ Not enforced |
| primary_key | ✅ Supported | ❌ Not enforced |
| foreign_key | ✅ Supported | ❌ Not enforced |
| unique | ✅ Supported | ❌ Not enforced |
| check | ✅ Supported | ❌ Not enforced |

</TabItem>
<TabItem value="Databricks" label="Databricks">

Currently, `not_null` and `check` constraints are supported and enforced only after a model builds. Because of this platform limitation, dbt considers these constraints `supported` but `not enforced`, which means they're not part of the "model contract" since these constraints can't be enforced at build time. This table will change as the features evolve.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like the identical Spark copy above, this paragraph is confusing.

I'd suggest rewriting for more clarity, potentially like the following:

Currently, not_null and check constraints are applied only after a model builds. Because of this platform limitation, dbt considers these constraints supported but not enforced, which means they're not part of the "model contract" since these constraints can't be enforced at build time. This table will change as the features evolve.


| Constraint type | Support | Platform enforcement |
|:----------------|:-------------|:---------------------|
| not_null | ✅ Supported | ❌ Not enforced |
| primary_key | ✅ Supported | ❌ Not enforced |
| foreign_key | ✅ Supported | ❌ Not enforced |
| unique | ✅ Supported | ❌ Not enforced |
| check | ✅ Supported | ❌ Not enforced |

</TabItem>
</Tabs>


## FAQs

### Which models should have contracts?
Expand Down
Loading