You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched the existing issues, and I could not find an existing issue for this bug
Current Behavior
We recently started working with model contracts. There are a lot of features of them that I like, especially ability to add constraints in Snowflake, which are then picked up by our ERD tool, but we are running into one issue.
If I intentionally make a change to a model that has a contract on it, and I update the yaml to match, when I run it in a CI job or a merge job (or any job that is deferring to a previous state) then I get an error and the job fails. In other words, I can never update a model that has a contract on it, even if I'm doing so intentionally.
I noticed that this issue had been raised before, and it looks like work was done to change this from an error to a warning, but did something then change again after that? Because I'm using an un-versioned model and I'm not getting a warning. I'm getting a full-on error, which is preventing me from being able to successfully merge this change. (I also noticed that this issue from just a few weeks ago also still references the fact that it should be a warning, not an error for un-versioned models).
Note that I'm also aware that there's a work around to version the model and then alias it back to the original name, but we're not interested in using model versions.
I also tried un-enforcing the contract and that throws an error as well.
Expected Behavior
I want my contracted models to throw errors if the model doesn't match the yaml. That feels useful. Like a "hey, your model is not what you claim it is".
I don't want my contracted-models to throw errors if the model matches the yaml but those have changed from a previous state. If I've bothered to update both the model and the yaml, that was probably quite intentional. It feels like its really tying my hands as a developer if I can never make changes to a model once it has a contract on it.
You could also consider allowing the developer to specify whether changes trigger errors, warnings, or nothing.
Steps To Reproduce
Add a contract to an unversioned model, push to production
Make a change to the model, and update the yaml to match
Try to run a CI or Merge job (or any job that defers to a previous state)
It fails with an error about breaking changes to a model with a contract
Relevant log output
No response
Environment
I'm working in dbt Cloud.
This is happening to me in the IDE when I run with defer to production toggled on. I'm not sure what version the IDE is on - is it always latest?
It is also happening in our Slim CI job which running in an environment that's on version 1.6.
Which database adapter are you using with dbt?
snowflake
Additional Context
No response
The text was updated successfully, but these errors were encountered:
Is this a new bug in dbt-core?
Current Behavior
We recently started working with model contracts. There are a lot of features of them that I like, especially ability to add constraints in Snowflake, which are then picked up by our ERD tool, but we are running into one issue.
If I intentionally make a change to a model that has a contract on it, and I update the yaml to match, when I run it in a CI job or a merge job (or any job that is deferring to a previous state) then I get an error and the job fails. In other words, I can never update a model that has a contract on it, even if I'm doing so intentionally.
I noticed that this issue had been raised before, and it looks like work was done to change this from an error to a warning, but did something then change again after that? Because I'm using an un-versioned model and I'm not getting a warning. I'm getting a full-on error, which is preventing me from being able to successfully merge this change. (I also noticed that this issue from just a few weeks ago also still references the fact that it should be a warning, not an error for un-versioned models).
Note that I'm also aware that there's a work around to version the model and then alias it back to the original name, but we're not interested in using model versions.
I also tried un-enforcing the contract and that throws an error as well.
Expected Behavior
I want my contracted models to throw errors if the model doesn't match the yaml. That feels useful. Like a "hey, your model is not what you claim it is".
I don't want my contracted-models to throw errors if the model matches the yaml but those have changed from a previous state. If I've bothered to update both the model and the yaml, that was probably quite intentional. It feels like its really tying my hands as a developer if I can never make changes to a model once it has a contract on it.
You could also consider allowing the developer to specify whether changes trigger errors, warnings, or nothing.
Steps To Reproduce
Add a contract to an unversioned model, push to production
Make a change to the model, and update the yaml to match
Try to run a CI or Merge job (or any job that defers to a previous state)
It fails with an error about breaking changes to a model with a contract
Relevant log output
No response
Environment
I'm working in dbt Cloud.
This is happening to me in the IDE when I run with defer to production toggled on. I'm not sure what version the IDE is on - is it always latest?
It is also happening in our Slim CI job which running in an environment that's on version 1.6.
Which database adapter are you using with dbt?
snowflake
Additional Context
No response
The text was updated successfully, but these errors were encountered: