-
Notifications
You must be signed in to change notification settings - Fork 36
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
[CT-2819] default__alter_relation_add_remove_columns macro does not use quoting with case sensitive Snowflake relation #256
base: main
Are you sure you want to change the base?
Conversation
Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide. |
NOTES: usage across adapters Adapters that use own implementation of Adapters that would use default if at all (not referenced in either adapter directly) |
… (course of original issue)
@@ -123,11 +123,11 @@ | |||
alter {{ relation.type }} {{ relation.render() }} | |||
|
|||
{% for column in add_columns %} | |||
add column {{ column.name }} {{ column.data_type }}{{ ',' if not loop.last }} | |||
add column {{ adapter.quote(column.name) }} {{ column.data_type }}{{ ',' if not loop.last }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we always want to quote? Or is there a config that we need to condition on, similar to the quote policy for relation names?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think adapter.quote leverages the same quote policy as relation names
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mikealfare are you thinking something like this (for relations) or this (for columns)?
In this particular case, I think we need to match the quoting from here (which would mean always quoting via adapter.quote()
). I forget the exact details -- and I could be wrong! -- but there's some notes under the "Root Cause" toggle in #250 (comment).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Side note: here are the primary resources I've been using when researching quoting or case-sensitive issues:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dbeatty10 oh these are really cool.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@colin-rogers-dbt adapter.quote()
will always quote.
@dbeatty10 If the objective is to always quote the column in this case, that's fine. I just know we've run into issues before where we quote something that doesn't get quoted, or vice versa, and then it fails a condition in a filter where it's supposed to pass. I haven't seen it with columns, so maybe it doesn't apply here.
assert "Job" in logs | ||
|
||
|
||
class TestIncrementalCaseSenstivityOnSchemaChange(BaseIncrementalCaseSenstivityOnSchemaChange): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need this class. The reason TestIncrementalOnSchemaChange
is there is to preserve backwards compatibility. These tests used to run when testing dbt-postgres
. Now that that's in its own repo and explicitly implements tests from dbt-tests-adapter
, we no longer need to create these classes here.
|
||
-- add a non-zero version to the end of the command to get a different version: | ||
-- --vars "{'version': 1}" | ||
select {{ dbt.current_timestamp() }} as inserted_at, 'john' as Name, 'engineer' as "Job" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if using adapter.quote
and/or string_literal
would enable this test to work across more adapters without modification?
select {{ dbt.current_timestamp() }} as inserted_at, 'john' as Name, 'engineer' as "Job" | |
select {{ dbt.current_timestamp() }} as inserted_at, {{ dbt.string_literal("john") }} as Name, {{ dbt.string_literal("engineer") }} as {{ adapter.quote("Job") }} |
@@ -303,3 +303,34 @@ | |||
|
|||
from source_data | |||
""" | |||
|
|||
_MODELS__SRC_ARTISTS = """ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: The content of the model looks like "jobs" now instead of "artists". So ideally they'd match instead of being different.
def test_run_incremental_check_quoting_on_new_columns(self, project): | ||
select = "src_artists dim_artists" | ||
run_dbt(["run", "--models", select, "--full-refresh"]) | ||
run_dbt(["show", "--inline", "select * from {{ ref('dim_artists') }}"]) | ||
res, logs = run_dbt_and_capture( | ||
["show", "--inline", "select * from {{ ref('dim_artists') }}"] | ||
) | ||
assert "Job" not in logs | ||
run_dbt(["run", "--vars", "{'version': 1}"]) | ||
run_dbt(["show", "--inline", "select * from {{ ref('dim_artists') }}"]) | ||
res, logs = run_dbt_and_capture( | ||
["show", "--inline", "select * from {{ ref('dim_artists') }}"] | ||
) | ||
assert "Job" in logs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The run_dbt(["show" ...
portions probably aren't necessary. They were just so people could see the state of the data within this reprex: #250 (comment)
Instead of the assertions here, you might be able to just rely upon expect_pass=True
as the default for run_dbt
and run_dbt_and_capture
.
From the original bug report in #250, my understanding was that it actually produced an error.
…lumn already exists
resolves #250
docs dbt-labs/docs.getdbt.com/#
Problem
Try to fix issue around case sensitive column quoting in macro
default__alter_relation_add_remove_columns
Solution
update the dbt-adapters default implementation test against postgres and other adapted as needed to maintain compaitiablity, update dbt-snowflake implementation of macro
create test in dbt-tests-adapters and inherit in adapters as needed.
Checklist