Explain consequences of placeholder value for ref
/source
during parsing
#2492
Labels
content
Improvements or additions to content
improvement
Use this when an area of the docs needs improvement as it's currently unclear
priority: medium
Fix or enhancement to existing information that’s creating some requests from customers
Contributions
Link to the page on docs.getdbt.com requiring updates
https://docs.getdbt.com/reference/dbt-jinja-functions/execute
What part(s) of the page would you like to see updated?
We could probably do a few things here:
Specific updates
Update the docs for
execute
to clarify how this affects the values ofref
,source
, and how oftenlog
output is generated.Other options:
execute
withinref
,source
, and/orlog
execute
pageAlternatively, we could make these docs update within pages for
ref
,source
, and/orlog
instead of withinexecute
.Additional information
Why
During parsing (
execute == False
),ref
andsource
render with a "dummy" value, and this has been confusing in multiple instances:{{ ref('anything') }}
in aset_sql_header
call resolves to the current model and not 'anything' dbt-core#2793 (comment)Side note: The dummy value it uses in particular is the rendering of
{{ this }}
which ends up being something likemy_database.my_schema.my_model
. Both surprising and confusing! We could imagine this being some other dummy value (likeNone.None.None
), which might be incrementally better, but still confusing when using these values during logging, conditional logic, etc.Example
Assume you have a relation named
relation
that you got via something like{% set relation = ref('my_model') %}
or{% set relation = source('source_name', 'table_name') %}
.This will yield surprising/confusing behavior during parsing:
But this will give the expected behavior (albeit surprisingly defensive, hence the need to put it in the docs):
The text was updated successfully, but these errors were encountered: