Closed GiorgiModebadzeW closed 1 month ago
Thanks for raising this @GiorgiModebadzeW !
I think the key thing that's happening is that dbt needs to know the data types for each column in your incremental model in order to mock it. So that's why it is running that DESCRIBE
statement within Snowflake.
The easiest way to overcome this is to first run your project using the --empty
flag (optionally selecting only your incremental models. Something like this:
dbt run --select "config.materialized:incremental" --empty
And after that, then you can do a regular build for that model:
dbt build --select my_model
Could you give that a shot and see if that works when your incremental table doesn't already exist?
Thanks @dbeatty10
I think that solves my issue
Is this a new bug in dbt-core?
Current Behavior
When creating unit test for the new incremental table and running it ,it fails if we test model in incremental mode. This is because after mocking "this" dbt before running the unit test tries to check if the table exists and if it does not fails. (For snowflake it runs DESCRIBE statement as the first step)
This is strange and cumbersome because unit tests are supposed to run before the model is run and because those tests can not pass model is never created. This created some kind of deadlock.
currently we need to first create table with (run) and then run unit tests- which defeats purpose of test in the first place and adds overhead for production
Expected Behavior
In the unit tests we already mock this. So there is no particular need why dbt needs to check if the table already exists. (maybe allow bypass?)
Steps To Reproduce
Create incremental table add unit test for the incremental check with
Run dbt build for this table and unit test will fail Run dbt run for this table and then dbt test or dbt build and unit test will pass.
Relevant log output
Environment
Which database adapter are you using with dbt?
snowflake
Additional Context
No response