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

Update contract.md to include specific rules (reverted to get tech review) #4258

Merged
merged 5 commits into from
Oct 11, 2023
Merged

Update contract.md to include specific rules (reverted to get tech review) #4258

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
363fd44
Revert "Revert "Update contract.md to include specific rules" (#4257)"
runleonarun Oct 11, 2023
92ce8e3
Update website/docs/reference/resource-configs/contract.md
runleonarun Oct 11, 2023
b41a723
Update contract.md
runleonarun Oct 11, 2023
3eeaead
Update website/docs/reference/resource-configs/contract.md
runleonarun Oct 11, 2023
3898632
Update website/docs/reference/resource-configs/contract.md
runleonarun Oct 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
6 changes: 4 additions & 2 deletions website/docs/reference/resource-configs/contract.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,9 +25,9 @@ This is to ensure that the people querying your model downstream—both inside a

The `data_type` defined in your YAML file must match a data type your data platform recognizes. dbt does not do any type aliasing itself. If your data platform recognizes both `int` and `integer` as corresponding to the same type, then they will return a match.

When dbt is comparing data types, it will not compare granular details such as size, precision, or scale. We don't think you should sweat the difference between `varchar(256)` and `varchar(257)`, because it doesn't really affect the experience of downstream queriers. If you need a more-precise assertion, it's always possible to accomplish by [writing or using a custom test](/guides/best-practices/writing-custom-generic-tests).
When dbt compares data types, it will not compare granular details such as size, precision, or scale. We don't think you should sweat the difference between `varchar(256)` and `varchar(257)`, because it doesn't really affect the experience of downstream queriers. You can accomplish a more-precise assertion by [writing or using a custom test](/guides/best-practices/writing-custom-generic-tests).

That said, on certain data platforms, you will need to specify a varchar size or numeric scale if you do not want it to revert to the default. This is most relevant for the `numeric` type on Snowflake, which defaults to a precision of 38 and a scale of 0 (zero digits after the decimal, such as rounded to an integer). To avoid this implicit coercion, specify your `data_type` with a nonzero scale, like `numeric(38, 6)`.
Note that you need to specify a varchar size or numeric scale, otherwise dbt relies on default values. For example, if a `numeric` type defaults to a precision of 38 and a scale of 0, then the numeric column stores 0 digits to the right of the decimal (it only stores whole numbers), which might cause it to fail contract enforcement. To avoid this implicit coercion, specify your `data_type` with a nonzero scale, like `numeric(38, 6)`. dbt Core 1.7 and higher provides a warning if you don't specify precision and scale when providing a numeric data type.

## Example

Expand All @@ -47,6 +47,8 @@ models:
- type: not_null
- name: customer_name
data_type: string
- name: non_integer
data_type: numeric(38,3)
```

</File>
Expand Down
Loading