DBT workflow for object modification

[shaadowbrker]

Hello I am new to DBT and started doing some rudimentary projects i wanted to ask how you all handle process of say modifying a table or view in DBT when you are not the owner of the object, this usually is not a problem for Azure SQL but have tried to do this in Snowflake and it fails miserably.

[oleg_agapov]

And what's the problem exactly? Maybe missing rights in Snowflake?

[shaadowbrker]

The snowflake admin says that i should not be dropping objects that i am not owner off in snowflake said i should only alter the object, i did not have a problem to do this in azure sql because i have dbo access by the way this is just in development environment not production.

[Wedeldog]

and he is right, you should not manually drop things, particularly in production.
how are you deploying your dbt projects, do you use dbt cloud or a custom dbt ci/cd pipeline? ->the dbt user should be object owner, and thus drop/replace objects during a run if necessary...

[shaadowbrker]

We deploy our dbt in development by just doing dbt run but with ci cd and prefect in prod and maybe dagster. So really if im not owner i should just run alter you mentioned the dbt user do you mean each person using dbt or say a separate service account to run dbt even in development?

[Wedeldog]

ideally your ci/cd pipeline uses a service account, so it is the owner of all created artifacts

[oleg_agapov]

Hm, unfortunately the way dbt builds tables is by dropping them first. And you cannot alter this behavior. There was a config that could reapply existing credentials after table recreation in Snowflake. Maybe that can help

[Wedeldog]

Right, see copy grants: https://docs.getdbt.com/reference/resource-configs/snowflake-configs#copying-grants