target-based Jinja rendering of vars in dbt_project.yml
See original GitHub issueDescribe the bug
When compiling / running models from dbt Cloud, the compiler does not correctly evaluate variables defined using jinja in dbt_project.yml
and referenced in a sources:
block.
Steps To Reproduce
Create in dbt_project.yml
:
vars:
database_prefix: "{% if target.name == 'dev' %}dev_{% else %}{% endif %}"
Create in sources.yml
:
sources:
- name: tpch
database: "{{ var('database_prefix') }}raw"
Expected behavior
SQL compilation will resolve the variable to either dev_
or an empty string when running either dbt compile
or dbt run
Screenshots and log output
On dbt compile
:
System information
Which database are you using dbt with?
- postgres
- redshift
- bigquery
- snowflake
- other (specify: ____________)
The output of dbt --version
:
0.18.1
The operating system you’re using: dbt Cloud
Issue Analytics
- State:
- Created 3 years ago
- Reactions:3
- Comments:5 (4 by maintainers)
Top Results From Across the Web
target-based Jinja rendering of vars in dbt_project.yml #3105
When compiling / running models from dbt Cloud, the compiler does not correctly evaluate variables defined using jinja in dbt_project.yml and ...
Read more >dbt_project.yml Context | dbt Developer Hub
The following context variables and methods are available when configuring resources in the dbt_project.yml file.
Read more >Template Designer Documentation - Jinja
A template contains variables and/or expressions, which get replaced with values when a template is rendered; and tags, which control the logic of...
Read more >Jinja2 Tutorial - Part 6 - Include and Import |
Jinja2 Tutorial - Part 1 - Introduction and variable substitution ... Jinja then inserts rendered text into the current template.
Read more >How to Write dbt Macros Using Jinja2 - Towards Data Science
In order to do this in Jinja simply plug in the variable you wish to print to ... models to be whatever is...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Thanks for the bug report @matt-winkler! I get that this is unexpected behavior. The truth is that
vars
indbt_project.yml
aren’t Jinja-rendered today. dbt needs to know the values ofvars
before it can render any other parts of the project. This leads to weirdness today wherebyvar()
is in the scope of thedbt_project.yml
context, but only if set by--vars
(docs).Ultimately, a solution here would be to clearly establish the parsing order of project files:
--vars
,dbt_version
, andbuiltins
are always availableprofile
--> gettarget
valuesvars
(with env vars,--vars
, andtarget
available)I’m definitely interested in rationalizing when
vars
are available, and what’s available to them: see https://github.com/fishtown-analytics/dbt/issues/2955. I don’t feel a ton of immediate priority here, though; in the use case you’re describing, there are several other ways to achieve this env-based behavior:{{ var('database_prefix') }}
with a (static string) value passed to--vars
{{ env_var() }}
insteadIf you do want dbt to handle the database prefixing on the basis of
target.name
alone, it’s not possible to get any DRYer than this:This issue has been marked as Stale because it has been open for 180 days with no activity. If you would like the issue to remain open, please remove the stale label or comment on the issue, or it will be closed in 7 days.