From e0c9f0785fcf8e33d06e4bf0d87c5ec94d06b458 Mon Sep 17 00:00:00 2001 From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com> Date: Thu, 17 Aug 2023 11:43:42 -0400 Subject: [PATCH] Adapter constraint support tables --- .../collaborate/govern/model-contracts.md | 79 +++++++++++++++++++ 1 file changed, 79 insertions(+) diff --git a/website/docs/docs/collaborate/govern/model-contracts.md b/website/docs/docs/collaborate/govern/model-contracts.md index 339098adbdc..0b3aae97ede 100644 --- a/website/docs/docs/collaborate/govern/model-contracts.md +++ b/website/docs/docs/collaborate/govern/model-contracts.md @@ -86,6 +86,85 @@ 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 + +Adapter-specific constraint support across platforms. + + + + + +| constraint type | support | +|:----------------|:-------------| +| not_null | 🌕 supported & enforced | +| primary_key | 🌗 supported; not enforced | +| foreign_key | 🌗 supported; not enforced | +| unique | 🌗 supported; not enforced | +| check | 🌑 not supported | + + + + +| constraint type | support | +|:----------------|:-------------| +| not_null | 🌕 supported & enforced | +| primary_key | 🌗 supported; not enforced | +| foreign_key | 🌗 supported; not enforced | +| unique | 🌗 supported; not enforced | +| check | 🌑 not supported | + + + + +| constraint type | support | +|:-----------------|:-------------| +| not_null | 🌕 supported & enforced | +| primary_key | 🌕 supported & enforced | +| foreign_key | 🌕 supported & enforced | +| unique | 🌑 not supported | +| check | 🌑 not supported | + + + + +| constraint type | support | +|:----------------|:-------------| +| not_null | 🌕 supported & enforced | +| primary_key | 🌕 supported & enforced | +| foreign_key | 🌕 supported & enforced | +| unique | 🌕 supported & enforced | +| check | 🌕 supported & enforced | + + + + +`not_null` and `check` constraints are supported and enforced. In the current implementation, however, these constraints are only enforced after a model builds. Due to this platform limitation, these are considered `supported` but `not enforced` and are not a part of the "model contract" since they can't be enforced at build time. This table will be updated as the features evolve. + +| constraint type | support | +|:----------------|:------------| +| not_null | 🌗 supported; not enforced | +| primary_key | 🌗 supported; not enforced | +| foreign_key | 🌗 supported; not enforced | +| unique | 🌗 supported; not enforced | +| check | 🌗 supported; not enforced | + + + + +`not_null` and `check` constraints are supported and enforced. In the current implementation, however, these constraints are only enforced after a model builds. Due to this platform limitation, these are considered `supported` but `not enforced` and are not a part of the "model contract" since they can't be enforced at build time. This table will be updated as the features evolve. + +| constraint type | support | +|:----------------|:------------| +| not_null | 🌗 supported; not enforced | +| primary_key | 🌗 supported; not enforced | +| foreign_key | 🌗 supported; not enforced | +| unique | 🌗 supported; not enforced | +| check | 🌗 supported; not enforced | + + + + + ## FAQs ### Which models should have contracts?