Type aliasing for model contract column data_type

[gshank]

resolves #8007

Problem

Currently contracts data_types must use the correct type for their warehouse, instead of using the built in type aliasing.

Solution

For model dictionaries provided by the provider context, convert the column data_type using the "translate_types" method.

Other teams

Affects adapter constraint tests, only BigQuery impacted: dbt-labs/dbt-bigquery#954

Checklist

• I have read the contributing guide and understand what's expected of me
• I have run this code in development and it appears to resolve the stated issue
• This PR includes tests, or tests are not required/relevant for this PR
• This PR has no interface changes (e.g. macros, cli, logs, json artifacts, config files, adapter interface, etc) or this PR has already received feedback and approval from Product or DX

[codecov]

Codecov Report

All modified lines are covered by tests ✅

Comparison is base (549dbf3) 86.43% compared to head (4084fc4) 86.43%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #8592   +/-   ##
=======================================
  Coverage   86.43%   86.43%           
=======================================
  Files         176      176           
  Lines       26009    26019   +10     
=======================================
+ Hits        22480    22490   +10     
  Misses       3529     3529           

Flag	Coverage Δ
integration	83.23% <100.00%> (+<0.01%)	⬆️
unit	64.86% <66.66%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
core/dbt/adapters/base/column.py	69.23% <ø> (ø)
core/dbt/context/providers.py	89.04% <100.00%> (+0.09%)	⬆️
core/dbt/contracts/graph/model_config.py	92.22% <100.00%> (+0.02%)	⬆️
core/dbt/contracts/graph/nodes.py	95.09% <100.00%> (+<0.01%)	⬆️
core/dbt/parser/base.py	93.63% <100.00%> (+0.05%)	⬆️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[aranke]

Is there a net new check we can add to ensure that some of the most complicated types are parsed correctly?

Otherwise, LGTM.

[gshank]

This causes test breakage in the adapter repos (mostly for test_constraints.py), at first glance mainly because of SQL in which statements such as "id integer not null" are replaced by "id int not null" because the TYPE_LABELS in the base Column class change INTEGER to INT (and STRING to TEXT).

@jtcohen6 @graciegoheen Just want to verify that this is something we actually want to have happen.

[gshank]

Note: currently it looks like string => text and integer => int are the only data types changed.

[aranke]

LGTM, can we add a test in case an adapter hasn't implemented the translate_type method?

[aranke]

What happens if the translate_type function fails? Can we do this instead?

column["data_type"] = self.adapter.Column.translate_type(orig_data_type) or column["data_type"]

Also, can we add a test for this scenario?

[gshank]

The base "translate_type" function return the passed in type if no translation exists. If the adapter hasn't implemented a different translate_type function it would use the base one.

[colin-rogers-dbt]

suggested change to changelog, but otherwise LGTM

[FishtownBuildBot]

Opened a new issue in dbt-labs/docs.getdbt.com: dbt-labs/docs.getdbt.com#4241