Skip to content
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

Changes for incremental strategy refactor compatibility #223

Merged
merged 2 commits into from
Jul 25, 2022

Conversation

gshank
Copy link
Contributor

@gshank gshank commented Jul 18, 2022

resolves #232

Description

Minimal changes to support compatibility with dbt Core incremental materialization refactor

Checklist

  • I have signed the CLA
  • I have run this code in development and it appears to resolve the stated issue
  • This PR includes tests, or tests are not required/relevant for this PR
  • I have updated the CHANGELOG.md and added information about my change to the "dbt-bigquery next" section.

@cla-bot cla-bot bot added the cla:yes label Jul 18, 2022
@gshank gshank marked this pull request as draft July 18, 2022 14:25
Copy link
Contributor

@jtcohen6 jtcohen6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm glad we didn't push the refactor all the way through in every repo, so we can see the (non-)impact on adapters that (a) have their own incremental materialization, and (b) haven't yet implemented the required pieces of the new strategy mechanism.

Comment on lines 49 to 51
{{ config.set('include_sql_header', true) }}
{{ get_insert_overwrite_merge_sql(target_relation, source_sql, dest_columns, [predicate]) }}
{{ config.set('include_sql_header', false) }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, this is clever! And does not feel any hackier than what we're doing right now.

Could we add a comment here, to the effect of:

/* {#
    because we're putting the model SQL _directly_ into the MERGE statement,
    we need to prepend the MERGE statement with the user-configured sql_header,
    which may be needed to resolve that model SQL (e.g. referencing a variable or UDF in the header)
    in the "dynamic" case, we save the model SQL result as a temp table first, wherein the
    sql_header is included by the create_table_as macro
#} */

@@ -14,7 +14,7 @@

{% macro dbt_bigquery_validate_get_incremental_strategy(config) %}
{#-- Find and validate the incremental strategy #}
{%- set strategy = config.get("incremental_strategy", default="merge") -%}
{%- set strategy = config.get("incremental_strategy") or 'merge' -%}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 This feels like a fair way to go until we can define as:

{% macro bigquery__get_incremental_default_sql(arg_dict) %}
  {{ return(get_incremental_merge_sql(arg_dict)) }}
{% endmacro %}

Understood that requires more work to get right, following the example in dbt-labs/dbt-snowflake#196

@jtcohen6
Copy link
Contributor

@gshank It does look a test started failing, relevant to the include_sql_header functionality:

FAILED tests/integration/bigquery_test/test_simple_bigquery_view.py::TestUnderscoreBigQueryRun::test_bigquery_run_twice
00:54:57  Database Error in model sql_header_model_incr_insert_overwrite_static (models/sql_header_model_incr_insert_overwrite_static.sql)
00:54:57    Function not found: a_to_b at [21:5]
00:54:57    compiled SQL at target/run/test/models/sql_header_model_incr_insert_overwrite_static.sql

I'm very glad we have a test for it, in some way shape or form

@gshank gshank force-pushed the check_incremental_strategy branch from 3d045a7 to 6e249dd Compare July 21, 2022 18:17
@gshank gshank changed the title Check incremental strategy refactor compatibility Changes for incremental strategy refactor compatibility Jul 21, 2022
@gshank gshank marked this pull request as ready for review July 21, 2022 18:22
@@ -46,6 +46,12 @@
)
{%- endset -%}

{#-- Because we're putting the model SQL _directly_ into the MERGE statement,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need sql comment symbols on each line?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason to put in the SQL comment lines is not because they help comment but because it makes the file highlighting look better :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An open question regarding that sql_header: is there a plan to detect them automatically these kind of headers to avoid the "unfriendly" approach of wrapping the code in a {%- call set_sql_header(config) %} block.
It requires dedicated documentation and mentoring on our end and I feel it could be simplified but maybe it's too much work for the overall usage?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[CT-889] Minimal changes to support dbt Core incremental materialization refactor
5 participants