[Bug] Setting time_ingestion_partitioning to True in model config, creates empty table in Bigquery

[Tonayya]

Is this a new bug in dbt-core?

• I believe this is a new bug in dbt-core
• I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior

When the flag time_ingestion_partitioning is set to True on a model, the table that is created in Bigquery is empty/has no rows.

Steps to Reproduce

• In a bare bone dbt Cloud project with a Bigquery connection, add a model as follows:

{{
    config(
        materialized="table",
        partition_by={
            "field": "created_at",
            "data_type": "timestamp",
            "granularity": "day",
            "time_ingestion_partitioning": true
        },
    )
}}

SELECT 1 as id, current_timestamp() as created_at

• Run dbt run --select partitioning_stuff
• We can see that no rows have been created:

• Checking in Bigquery, we can see that the table is empty:

• Dropping the table in Bigquery, then changing the model code to the below, where we remove the time_ingestion_partitioning flag:

{{
    config(
        materialized="table",
        partition_by={
            "field": "created_at",
            "data_type": "timestamp",
            "granularity": "day"
        },
    )
}}

SELECT 1 as id, current_timestamp() as created_at

• Running dbt run --select partitioning_stuff
• We can see that 1 row is created as expected:

• Checking in Bigquery, we can see that the row is created as expected as well:

Expected Behavior

Tables should not be empty.

Steps To Reproduce

As outlined above.

Relevant log output

Environment

- OS:
- Python:
- dbt:

Which database adapter are you using with dbt?

No response

Additional Context

No response

[meioli]

+1

[trangkramp]

+1

[dbeatty10]

Thanks for opening this @Tonayya !

Since time_ingestion_partitioning is BigQuery-specific behavior, I'm going to transfer this to dbt-adapters repo where the code for the dbt-bigquery adapter is hosted.

Original issue in dbt-core: #866