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

[Future scope] Distinguish 'inferred' vs 'partial' contracts #3998

Merged
merged 2 commits into from
Sep 11, 2023
Merged

[Future scope] Distinguish 'inferred' vs 'partial' contracts #3998

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5467179
Distinguish 'inferred' vs 'partial' contracts
jtcohen6 Aug 31, 2023
e01c10e
Merge branch 'current' into jerco/clarify-model-contract-inferred-par…
mirnawong1 Sep 11, 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
8 changes: 5 additions & 3 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 @@ -192,11 +192,12 @@ In some cases, you can replace a test with its equivalent constraint. This has t

**Why aren't tests part of the contract?** In a parallel for software APIs, the structure of the API response is the contract. Quality and reliability ("uptime") are also very important attributes of an API's quality, but they are not part of the contract per se. When the contract changes in a backwards-incompatible way, it is a breaking change that requires a bump in major version.

### Can I define a "partial" contract?
### Do I need to define every column for a contract?

Currently, dbt contracts apply to **all** columns defined in a model, and they require declaring explicit expectations about **all** of those columns. The explicit declaration of a contract is not an accident—it's very much the intent of this feature.

We are investigating the feasibility of supporting "inferred" or "partial" contracts in the future. This would enable you to define constraints and strict data typing for a subset of columns, while still detecting breaking changes on other columns by comparing against the same model in production. If you're interested, please upvote or comment on [dbt-core#7432](https://github.com/dbt-labs/dbt-core/issues/7432).
At the same time, for models with many columns, we understand that this can mean a _lot_ of yaml. We are investigating the feasibility of supporting "inferred" contracts. This would enable you to define constraints and strict data typing for a subset of columns, while still detecting breaking changes on other columns by comparing against the same model in production. This isn't the same as a "partial" contract, because all columns in the model are still checked at runtime, and matched up with what's defined _explicitly_ in your yaml contract or _implicitly_ with the comparison state. If you're interested in "inferred" contract, please upvote or comment on [dbt-core#7432](https://github.com/dbt-labs/dbt-core/issues/7432).


### How are breaking changes handled?

Expand All @@ -207,4 +208,5 @@ Breaking changes include:
- Changing the `data_type` of an existing column
- Removing or modifying one of the `constraints` on an existing column (dbt v1.6 or higher)

More details are available in the [contract reference](/reference/resource-configs/contract#detecting-breaking-changes).
More details are available in the [contract reference](/reference/resource-configs/contract#detecting-breaking-changes).

Loading