new paradigm for creating replacing and dropping relations

[dataders]

What

Restructure macros so that operations so that within a materialization, macros need not get more relation-specific.

This means there's now a catch all macro that can be used regardless of the underlying relation type

examples

drop_relation()

{% macro default__drop_relation(relation) -%}
    {% call statement('drop_relation', auto_begin=False) -%}
        {%- if relation.is_table -%}
            {{- drop_table(relation) -}}
        {%- elif relation.is_view -%}
            {{- drop_view(relation) -}}
        {%- elif relation.is_materialized_view -%}
            {{- drop_materialized_view(relation) -}}
        {%- else -%}
            drop {{ relation.type }} if exists {{ relation }} cascade
        {%- endif -%}
    {%- endcall %}
{% endmacro %}

get_create_intermediate_sql()

{%- macro default__get_create_intermediate_sql(relation, sql) -%}

    -- get the standard intermediate name
    {% set intermediate_relation = make_intermediate_relation(relation) %}

    -- drop any pre-existing intermediate
    {{ get_drop_sql(intermediate_relation) }};

    {{ get_create_sql(intermediate_relation, sql) }}

{%- endmacro -%}

Why

Before MV/DTs, when materializing a dbt model as a table or view, dbt would first check if the target name already existed, and drop it if so.

For example, when creating a table with the target three-part name foo.bar.baz, dbt will check to see if that name is being already used by a view.

Furthermore, dbt’s out-of-the-box materializations will create backup and temp objects so if dbt run fails, the user is back to where they started, instead of having dropped all database objects were in dbt’s way.

Now, dbt must also check that the current model and corresponding backup and temp relations won’t collide with any existing materialized views.

The two-adapter related features here are

• checking if a relation exists, and if so, what type it is
• dropping a relation

Relevant PRs

• ADAP-869: Support atomic replace in replace macro dbt-labs/dbt-core#8539
• ADAP-814: Refactor prep for MV updates dbt-labs/dbt-core#8459
• ADAP-821: Refactor prep for dynamic table / table/view swap dbt-labs/dbt-snowflake#751
• ADAP-821: Add support for replacing dynamic tables with tables/views and vice versa dbt-labs/dbt-snowflake#753

@benc-db if this strikes you as a lot of moving pieces and I haven't yet explained everything, you'd be right! Please let me know how I can help. Thanks for agreeing to being our guinea pig

[benc-db]

@dataders can you schedule a meeting with me and either you or someone else from your team to go over the details. I did what was called out in the migration guide for 1.7.0, but I suspect this work was pushed out along with MV/ST and want to make sure I have all the context before I pick it back up.

[benc-db]

Going to close this issue as we've got an implementation for MV in review.