[CT-2038] Detect breaking changes to column names and data types in state:modified check

[MichelleArk]

If a model with contract:true has its column name/data types modified in a way that represents a breaking change, dbt should raise an error as part of the state:modified check.

What constitutes a breaking change?

• Removal of column
• name change of column
• data_type change of column
• changing contract:true to contract:false

[jtcohen6]

Do we want this exception to be limited to commands where the user has explicitly selected state:modified? Or as soon as previous state is established? Although it feels a bit odd, I think I'm okay with raising it only when state:modified is selected.

We could also add a new sub-selector, state:modified.contracts.

Implementation detail: We have a number of same_* methods (example) which power state:modified selection today. It could make sense to define a same_contract method, with these return values:

• True if the contract is the same (including models without contracts)
• False is the contract has changed, in a non-breaking way
• Raises an exception if the contract has changed in a breaking way

[MichelleArk]

error message should direct users to create a new version and point to versioning docs: https://docs.getdbt.com/docs/collaborate/publish/model-versions

[gshank]

What about order? If the order of the columns changes should it be considered modified or not?

[gshank]

If contracts are set to false in both old and new states, then I assume that even if the the columns names or data_types change, that is not a breaking change?

[jtcohen6]

What about order? If the order of the columns changes should it be considered modified or not?

For now, we're going to say that column order doesn't matter. We might add this as a configuration option later on if lots of users request it.

If contracts are set to false in both old and new states, then I assume that even if the the columns names or data_types change, that is not a breaking change?

Correct! Adopting the terminology / data structure proposed in #7184:

• If old contract: {enforced: false} + new contract: {enforced: false} → never a breaking change
• If old contract: {enforced: false} + new contract: {enforced: true} → never a breaking change
• If old contract: {enforced: true} + new contract: {enforced: true} → detect breaking changes, following the logic in the description
• If old contract: {enforced: true} + new contract: {enforced: false} → always a breaking change!

[gshank]

Currently when old has contract false and new has contract true, it will show as modified because the config has changed: unrendered_config = {'contract': True, 'materialized': 'table'}

[jtcohen6]

Yes! It's definitely a change, and the model should be selected to run by state:modified / in CI. It's just not a breaking change, so it shouldn't raise an error.

[gshank]

@MichelleArk I've removed including "constraints" in the checksum, since it looks like that's not part of this ticket. Let me know if you want something different.