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 when you run a full-refresh with dbt-trino it will drop the target table and attempt to re-create it. We have adopted a practice of manually taking backups before doing full-refresh of large tables. If users try to access the data while it is refreshing they get an error.
My proposal is to create the new table with the __dbt_tmp suffix and only after successful creation drop the target table and rename the __dbt_tmp table.
This way data stays available to users and no manual rollback is needed if the full refresh does not succeed.
Describe alternatives you've considered
Manual workaround is easy but annoying
Who will benefit?
Users and Developers will benefit as there is less margin for error and better data availability
Are you willing to submit PR?
Yes I am willing to submit a PR!
The text was updated successfully, but these errors were encountered:
Hi @lutzkuen, what is the target connector you're using? We are working on adding support for CREATE OR REPLACE in the engine which could help with the issue and it could replace creating temp tables.
We are using dbt-trino with both starburst and Trino on Iceberg. When create or replace is going to be supported by the engine that would make a much easier solution
Describe the feature
Right now when you run a full-refresh with dbt-trino it will drop the target table and attempt to re-create it. We have adopted a practice of manually taking backups before doing full-refresh of large tables. If users try to access the data while it is refreshing they get an error.
My proposal is to create the new table with the __dbt_tmp suffix and only after successful creation drop the target table and rename the __dbt_tmp table.
This way data stays available to users and no manual rollback is needed if the full refresh does not succeed.
Describe alternatives you've considered
Manual workaround is easy but annoying
Who will benefit?
Users and Developers will benefit as there is less margin for error and better data availability
Are you willing to submit PR?
The text was updated successfully, but these errors were encountered: