Skip to content

Commit

Permalink
Built in aliasing for data_type
Browse files Browse the repository at this point in the history
  • Loading branch information
matthewshaver committed Oct 11, 2023
1 parent ba6e2a8 commit 933bbab
Showing 1 changed file with 23 additions and 0 deletions.
23 changes: 23 additions & 0 deletions website/docs/reference/resource-configs/contract.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,8 +23,31 @@ When the `contract` configuration is enforced, dbt will ensure that your model's

This is to ensure that the people querying your model downstream—both inside and outside dbt—have a predictable and consistent set of columns to use in their analyses. Even a subtle change in data type, such as from `boolean` (`true`/`false`) to `integer` (`0`/`1`), could cause queries to fail in surprising ways.

<VersionBlock lastVersion="1.6">

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.

</VersionBlock>

<VersionBlock firstVersion="1.7">

dbt uses built-in type aliasing for the `data_type` defined in your YAML. For example, you can specify `string` in your contract, and on Postgres/Redshift, dbt will convert it to `text`. If dbt doesn't recognize the `data_type` name among its known aliases, it will pass it through as-is. This is enabled by default, but you can opt-out by setting `alias_types` to `false`.

Example:

```yml

models:
- name: my_model
config:
contract:
enforced: true
alias_types: false # true by default

```

</VersionBlock>

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

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

0 comments on commit 933bbab

Please sign in to comment.