-
Notifications
You must be signed in to change notification settings - Fork 178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] Support pre-flight checks for dbt model contacts on dynamic tables #888
Comments
Dynamic tables do not currently support model contracts. Please see the docs for more information. I'll reclassify this as an enhancement in the meantime. Hopefully this is a feature that we can take on soon. |
The typical flow of working with contract would be that you start working with View or Table and only then switch to Dynamic Table (especially that it's not GA in Snowflake yet), so that limitation mentioned in Contract documentation is something that I missed completely. Ideally it could be mentioned here as well https://docs.getdbt.com/reference/resource-configs/snowflake-configs#limitations |
That's fair. I'll open a docs ticket for that. This ticket (888) will pertain to the actual implementation of of model contracts for DTs. |
We also want to incorporate sanity testing cases into completing this issue |
Closing this because we did update the docs |
@amychen1776 - not sure if closing is the right thing - updating docs (saying it's not working) was a separate issue (dbt-labs/docs.getdbt.com#4869), but ultimately the contract verification should be implemented for Dynamic Tables as well, especially that its GA on Snowflake already. |
Ah you're right - I was skimming and misread the above message. Will reopen now |
@awal11 I just dug into this and we had a conversation with the Snowflake team about this. Contract verification is not supported for Dynamic tables. While I tried to reproduce on snowsight, I get this error message Which the Snowflake DT confirmed is expected. Do you have information otherwise? |
@amychen1776 - hmm, now I am confused....
and to my understanding this is rather an internal dbt check against metadata, similar to what already happens with views or tables, so I really do not understand how your screenshot is related to it... |
Okay, @dbeatty10 dug into this and validated that we can do pre-flight checks separately from applying model constraints despite the fact that they're defined in the same place. We don't have capacity in the short term to tackle this but we will scope this out for our next quarter. |
@colin-rogers-dbt a note for when we refine this - we should scope this out to support MVs on the other adapters. |
…5993) [Preview](https://docs-getdbt-com-git-dbeatty10-patch-1-dbt-labs.vercel.app/docs/collaborate/govern/model-contracts#where-are-contracts-supported) ## What are you changing in this pull request and why? - It isn't clear if materialized views have support for model contracts or not. - Also not clear if custom materializations automatically include support for model contracts or not. Context: dbt-labs/dbt-snowflake#888 (`dynamic table` is the Snowflake equivalent of `materialized view` in other data platforms) ## Checklist - [x] I have reviewed the [Content style guide](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/content-style-guide.md) so my content adheres to these guidelines.
Is this a new bug in dbt-snowflake?
Current Behavior
When I deploy models materialized as table or view - the contract is verified and in case of discrepancy I receive the expected error
When I deploy models materialized as dynamic_table - the contract verification does not seem to happen, so can I release things that have not been vetted and can violate the contract.
This behavior is completely unexpected and when unnoticed will have nasty consequences discovered only on target environment (as was my case).
Expected Behavior
The models deployed as dynamic_tables should have the contract enforced, similarly to other materializations.
At minimum - there should be some warning emitted that this is not the case for dynamic tables
Steps To Reproduce
Relevant log output
No response
Environment
Additional Context
No response
The text was updated successfully, but these errors were encountered: