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
right now, for model contracts, we rely on the catalog.json artifact for column information. Using the artifact assumes that the models exist in the environment we're running the package in, and can lead to some issues if the models do not yet exist.
This is a challenge to manage when
Models are renamed with the version operation (fix: do any contract operations first)
Users have not run a whole dbt run in dev before attempting to use this package.
Should we think about some sort of dry-run mode to stub in metadata only models before all ops (select * from ... where false)? Is it more reliable to leverage the get_columns_in_query macro, perhaps as a run operation?
The text was updated successfully, but these errors were encountered:
Would another option be to allow "importing" a catalog.json that was generated from prod?
Or, to try the technique of ... where false, could we overwite the ref function to replace ref("my_model") by ( select * from ref("my_model") where false )
right now, for model contracts, we rely on the
catalog.json
artifact for column information. Using the artifact assumes that the models exist in the environment we're running the package in, and can lead to some issues if the models do not yet exist.This is a challenge to manage when
dbt run
in dev before attempting to use this package.Should we think about some sort of dry-run mode to stub in metadata only models before all ops (
select * from ... where false
)? Is it more reliable to leverage theget_columns_in_query
macro, perhaps as a run operation?The text was updated successfully, but these errors were encountered: