[CT-2197] [Feature] Detect breaking changes to constraints in state:modified check

[MichelleArk]

If a model with contract: True has its constraints 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?

• Removing a (column or model-level) constraint that is enforced by the data warehouse
• Changing the materialization from table to view or ephemeral on a model that has at least one enforced constraint.

---

Blocked by:

• [CT-2198] Unify constraints and constraints_check configs #7066
• [CT-2199] Generalize constraint compatibility warnings #7067
• [CT-1922] Support 'constraints' as a model-level property #6754

[jtcohen6]

Also a breaking change: You have a model with at least one constraint defined that the data platform can enforce. You switch the materialization of that model from table or incremental, to view — because data platforms do not support constraints on views.

[MichelleArk]

You switch the materialization of that model from table or incremental, to view

or to ephemeral!

[jtcohen6]

Good point! We really shouldn't allow ephemeral models to be contract: true or access: public in the first place

[emmyoop]

We are unclear on exactly what we would be checking has changed and how often. There's concern this would cause a slowdown in detecting changes if we have to check every single column for every model with a contract.

[sadahry]

We think this feature will be useful for us,
so I'd like to ask you about this spec.

We've tried using dbt-core==1.5.0-b5 ,
and found disallowing adding new columns to yml in this version.

e.g.,

before

version: 2

models:
  - name: sometable
    config:
      contract:
        enforced: true
    columns:
      - name: order_id
        data_type: number

      - name: order_name
        data_type: varchar

after -> then failed with dbt.exceptions.ModelContractError

version: 2

models:
  - name: sometable
    config:
      contract:
        enforced: true
    columns:
      - name: order_id
        data_type: number

      - name: order_name
        data_type: varchar

      - name: categories
        data_type: varchar

This is what you excepted?

I read it and found this description.

Additive changes are not considered breaking:

• adding a new column to a contracted model
  https://docs.getdbt.com/reference/resource-configs/contract#detecting-breaking-changes

My understanding is that it means allow adding columns in yaml, but current behavior does not.
Allowing adding columns is useful for us because our model's are updated in a fast cycle.

I'd like to know if this specification is as expected
or if there is a mistake in me or dbt-core.

[jtcohen6]

@sadahry Thanks for trying out the beta, and for the clear reproduction case! I agree that's not the intended behavior. It should be possible to add a new column without raising a ModelContractError (breaking change). I'll open a bug report now.

[jtcohen6]

@sadahry This will be fixed in #7333. Thank you so much for catching this! I'm very glad we were able to get the behavior working as intended before cutting the v1.5 release candidate.

We'll be swinging back to this issue for v1.6, to add in the scope of raising an exception on breaking changes to constraints. That is, any removals or modifications — but additions are totally okay!

[sadahry]

Thank you for your quick fix! And looking forward to the enhancement for v1.6 👍