Skip to content

Commit

Permalink
Adapter constraint support tables (#3944)
Browse files Browse the repository at this point in the history
[Preview](https://deploy-preview-3944--docs-getdbt-com.netlify.app/docs/collaborate/govern/model-contracts#platform-constraint-support)

## What are you changing in this pull request and why?
Adding tables outlining adapter-specific constraint support to the model
contracts page

## Checklist

- [x] Review the [Content style
guide](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/content-style-guide.md)
and [About
versioning](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/single-sourcing-content.md#adding-a-new-version)
so my content adheres to these guidelines.
- [x] Add a checklist item for anything that needs to happen before this
PR is merged, such as "needs technical review" or "change base branch."
  • Loading branch information
matthewshaver authored Aug 21, 2023
2 parents 321f002 + 17d98d7 commit 344f794
Showing 1 changed file with 85 additions and 0 deletions.
85 changes: 85 additions & 0 deletions website/docs/docs/collaborate/govern/model-contracts.md
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.



<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.

| 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.

| 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

0 comments on commit 344f794

Please sign in to comment.