Incremental table is fully rebuilt if relation with different capitalization exists

[darrylng]

This is in between an observation and a question to those more familiar with the codebase.

Observation

We have an incremental table that is recently fully rebuilt (CREATE TABLE instead of MERGE) despite the table being present in BigQuery. Our table name is not capitalized, and we recently toyed with the idea to make all table names consistent and therefore created an identical table that is capitalized, and that's when the issue started occurring.

Example

• If only table abc exist, a model abc.sql will correctly have the abc table incrementally merged
• If both tables Abc and abc exist, a model Abc.sql will correctly have the Abc table incrementally merged
• If both tables Abc and abc exist, a model abc.sql will cause the table to be fully rebuilt on dbt run (this discussion)

abc.sql:

{{ config(materialized="incremental") }}
SELECT 1 AS id

Code comprehension

Incremental logic will create table if model does not exist in BigQuery, as shown in this line.
If my code comprehension is correct:

• load_relation() calls load_cached_relation()
• load_cached_relation() calls the adapter's get_relation() here
• the adapter's get_relation() then calls google.cloud.bigquery API to determine if the table exist. From my local testing using python, the API correctly returns if the table exists, and is case-sensitive. ie: abc is found, and Abc is also found, separately.

Question

So is this a bug in dbt? I know this probably shouldn't happen much as having two tables with the same name but with different capitalization is odd, but still begs the question if this is an expected behaviour. The full rebuild despite table exists for incremental merge might cause some people a lot of money if the table happens to be a big one.