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
This request was initially surfaced here in dbt slack.
Hi there. It is possible to use Jinja inside dbt_project to dynamically build the schema name for different environments when used in a package variable? I'm using dbt_artifacts and want the schema to be adt (stands for audit) in prod, but <target.user>_adt in dev.
The goal here is for the dbt_artifacts_schema (currently set in vars) to be dynamic, based on user name and environment.
@jaypeedevlin and I played around with using the generate_schema_name macro to do this. It works fine in create_dbt_artifacts_tables() to replace the logic in the set database_name (here) with logic that utilizes the generate_database_name() macro. The problem arises when we attempt to update the database in the sources.yml file (here). The macro isn't acceptable in this file, and therefore this solution isn't feasible.
Two proposed approaches for tackling this would be:
Make the source tables in to dbt models so that we can utilize the generate_schema_name() macro
Make some assumptions about how users will structure their projects and create vars that reflect those assumptions. (For instance, a prod and dev location for the artifacts.)
The text was updated successfully, but these errors were encountered:
This request was initially surfaced here in dbt slack.
The goal here is for the
dbt_artifacts_schema
(currently set in vars) to be dynamic, based on user name and environment.@jaypeedevlin and I played around with using the
generate_schema_name
macro to do this. It works fine increate_dbt_artifacts_tables()
to replace the logic in theset database_name
(here) with logic that utilizes thegenerate_database_name()
macro. The problem arises when we attempt to update the database in thesources.yml
file (here). The macro isn't acceptable in this file, and therefore this solution isn't feasible.Two proposed approaches for tackling this would be:
generate_schema_name()
macroprod
anddev
location for the artifacts.)The text was updated successfully, but these errors were encountered: