Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explain consequences of placeholder value for ref/source during parsing #2492

Open
1 task done
dbeatty10 opened this issue Dec 5, 2022 · 0 comments
Open
1 task done
Assignees
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

Comments

@dbeatty10
Copy link
Contributor

dbeatty10 commented Dec 5, 2022

Contributions

  • I have read the contribution docs, and understand what's expected of me.

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:

  1. Separate a short and simple explanation from the gory details
  2. Create a stand-alone section explaining parsing vs. execution
  3. Create a separate "examples" section (including the one given below)

Specific updates

Update the docs for execute to clarify how this affects the values of ref, source, and how often log output is generated.

Other options:

  • link to these docs in execute within ref, source, and/or log
  • find or create relevant discussions in Discourse and link to them within the execute page

Alternatively, we could make these docs update within pages for ref, source, and/or log instead of within execute.

Additional information

Why

During parsing (execute == False), ref and source render with a "dummy" value, and this has been confusing in multiple instances:

Side note: The dummy value it uses in particular is the rendering of {{ this }} which ends up being something like my_database.my_schema.my_model. Both surprising and confusing! We could imagine this being some other dummy value (like None.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:

{%- if load_relation(relation) is none -%}
    {{ log("Relation is missing: " ~ relation, True) }}
{% endif %}

But this will give the expected behavior (albeit surprisingly defensive, hence the need to put it in the docs):

{%- if execute and load_relation(relation) is none -%}
    {{ log("Relation is missing: " ~ relation, True) }}
{% endif %}
@dbeatty10 dbeatty10 added content Improvements or additions to content improvement Use this when an area of the docs needs improvement as it's currently unclear labels Dec 5, 2022
@dbeatty10 dbeatty10 self-assigned this Dec 5, 2022
@runleonarun runleonarun added the priority: medium Fix or enhancement to existing information that’s creating some requests from customers label Jun 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

2 participants