-
Notifications
You must be signed in to change notification settings - Fork 495
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
"if not target_relation" is not true even if relation does not exist in get_column_values #444
Comments
Thanks for the great writeup and repro case @mothiki! @jtcohen6 I made this change in #440 to solve #424. Can you think of any way of squaring this circle and supporting both use cases? Potentially we need to still use the If we have to choose only one winner, I think we have to leave this as-is and put the onus on the macro user to create their own Relation if they think it may not exist. I don't like it but I think it's more important to allow people to access Relations that do exist, no matter what weird quoting they have, than support not accessing Relations that don't. @mothiki is the relation not existing yet a common use case for you, or something that bit you as a one-off? (Perhaps unintuitively, if it's a one-off I feel worse about leaving it in a broken state.) |
Oof, lots going on for this one! Thanks for wading through the muck to get here. It sounds like we need to find a way to do all of the following:
So perhaps something like: {%- set existing_relation = load_relation(table) -%} {# this is shorthand for get_relation() #}
{%- if existing_relation -%}
{# it exists, use it! #}
{%- set target_relation = table -%}
{%- else -%}
{# it doesn't exist, so we'll opt for the default further down #}
{%- set target_relation = None -%}
{%- endif -%} |
@joellabes @jtcohen6, Thanks for the detailed explanation. |
Only for visibility: We are facing the same issue, as we use the default value introduced by @emilieschario for this purpose. For now, I will go ahead and use a custom macro, but will follow what is going on here |
Thanks @chodera! Intending to get a bugfix release out for this in the next week or so 🤞 Worth noting that you can also go back to 0.7.3 in the meantime! |
Describe the bug
In
dbt_utils<0.7.4
, while usingget_column_values
macro,dbt compile
on a dummy schema that doesn't exist in the database yet, returns thedefault
values specified in the macro.But, In
dbt_utils==0.7.4
,dbt compile
is trying to query the column values even though the table does not exist yet and throwsschema <dummy_schema_1111> does not exist
error.Steps to reproduce
Step 1:
This is a sample model that we have.
Step 2:
Set
schema
inprofiles.yml
to a dummy value.Step 3:
run
dbt compile
Expected results
Previously the macro has:
which sets
target_relation
to null when it doesn't exist and the code return default values['email', 'call']
and the compilation succeeds without querying the database.Actual results
Now since the code is changed to:
it returns
schema does not exist
error.System information
The contents of your
packages.yml
file:Which database are you using dbt with?
The output of
dbt --version
:Additional context
The code doesn't go to the below block even if the relation doesn't exist in the database:
Are you interested in contributing the fix?
Yes, I would love to contribute.
The text was updated successfully, but these errors were encountered: