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
Currently materialized views with auto-refresh won't rebuild when the definition of the DBT model has changed. It is good that DBT doesn't refresh the views when either the calculated view is unchanged, but it definitely should be deployed the definition was changed.
I see two solutions for this:
Check if the definition of the materialized view changed on the user's machine
Check if the calculated materialized view differs from the materialized view that is currently deployed
I think the latter is the more elegant one, but I don't know which are feasible given the options working within dbt macro's.
The fix could either be applied in the refresh_materialized_view methods which are dependent on the specific data warehouse or extending the elif statement in line 19 of default/materialized_view to include one of the checks mentioned above.
The text was updated successfully, but these errors were encountered:
@Luttik Love that you're thinking about this! What do you think about leveraging dbt's state-based selection to accomplish this? Then this would look something like:
# "full refresh" all MVs that have changes
dbt -s state:modified,config.materialized:materialized_view --full-refresh
# partial refresh of MVs without changes
dbt -s config.materialized:materialized_view --exclude state:modified
I'm not sure if I'm tracking completely. However, I think that this should just work automagically without having to specify anything in addition to the dbt run command, after a run you expect the live definitions to be in-sync with your dbt definitions.
Not refreshing data vs not syncing the model is very different in my eyes, the first will correct itself at some point while the latter does not.
hey @Luttik thanks for opening this issue! Even though MVs & DTs now live in Core, this limitation that you call out still existis. I'm closing this issue in favor of dbt-labs/dbt-adapters#234 so that we can track the use case and priority over there moving forward
Currently materialized views with auto-refresh won't rebuild when the definition of the DBT model has changed. It is good that DBT doesn't refresh the views when either the calculated view is unchanged, but it definitely should be deployed the definition was changed.
I see two solutions for this:
I think the latter is the more elegant one, but I don't know which are feasible given the options working within dbt macro's.
The fix could either be applied in the
refresh_materialized_view
methods which are dependent on the specific data warehouse or extending theelif
statement in line 19 ofdefault/materialized_view
to include one of the checks mentioned above.The text was updated successfully, but these errors were encountered: