Open jeremyyeo opened 5 days ago
That is returning false
for target_relation_exists
...
{% macro check() %}
{% do log(adapter.get_relation(database="development_jyeo", schema="dbt_jyeo_snapshot", identifier="snappy")) %}
{% do log(adapter.get_relation(database=" development_jyeo", schema="dbt_jyeo_snapshot", identifier="snappy")) %}
{% endmacro %}
$ dbt run-operation check
01:12:51 Running with dbt=1.8.2
01:12:52 Registered adapter: snowflake=1.8.3
01:12:52 Found 1 model, 1 snapshot, 446 macros
01:12:55 "DEVELOPMENT_JYEO"."DBT_JYEO_SNAPSHOT"."SNAPPY"
01:12:55 None
Incrementals do a check for existing from the cache: https://github.com/dbt-labs/dbt-adapters/blob/e964302121f70bacc8f827683c329e06696216cf/dbt/include/global_project/macros/materializations/models/incremental/incremental.sql#L5
Thanks for reporting this @jeremyyeo -- we do not want it to be possible to overwrite a pre-existing snapshot and incur the accompanying data loss!
It looks to me like the Snowflake default quoting
config is coming into play here.
So I added this to your reprex in order to be explicit:
# dbt_project.yml
# Turn off quoting (which is the default for Snowflake)
quoting:
database: false
schema: false
identifier: false
In some local testing, it looked like updating this line to using Jinja's trim()
filter could be a fix for the issue:
database=model.database|trim,
However, I'm guessing that there is some other whitespace trimming that is happening for models but not for snapshots in our Python code somewhere. So rather than my fix above, we'd probably opt for that trimming the snapshot target_database
value in Python instead.
Is this a new bug in dbt-core?
Current Behavior
Potential footgun - If you forget to remove whitespace from the
target_database
config of snapshots - dbt will fail to detect that the snapshot already exist and therefor does a CTAS everytime.Expected Behavior
This doesn't happen for incremental models - as in, even if we had a whitespace for the
database
config, dbt will correctly detect that the model already exist and insert/merge as expected. Snapshots should follow this too.Steps To Reproduce
Both
foo
andsnappy
did a CTAS as expected - cause they don't yet exist in the database.foo
already exist so it is inserted into - expected.snappy
already exist but it is replaced instead of merged into - unexpected.Do a quick switch over to dbt 1.8 and build to see that this problem still exist:
Relevant log output
No response
Environment
Which database adapter are you using with dbt?
snowflake
Additional Context
If you do this on postgres - you get a cross-db error with the whitespace showing: