Skip to content

fix: failure when config from view to Iceberg table #367

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

Merged
merged 3 commits into from
Aug 10, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 29 additions & 20 deletions dbt/include/athena/macros/materializations/models/table/table.sql
Original file line number Diff line number Diff line change
Expand Up @@ -82,27 +82,36 @@
{{ create_table_as(False, target_relation, sql) }}
{%- endcall %}
{%- else -%}
{%- if tmp_relation is not none -%}
{%- do drop_relation(tmp_relation) -%}
{%- endif -%}

{%- set old_relation_bkp = make_temp_relation(old_relation, '__bkp') -%}
-- If we have this, it means that at least the first renaming occurred but there was an issue
-- afterwards, therefore we are in weird state. The easiest and cleanest should be to remove
-- the backup relation. It won't have an impact because since we are in the else condition,
-- that means that old relation exists therefore no downtime yet.
{%- if old_relation_bkp is not none -%}
{%- do drop_relation(old_relation_bkp) -%}
{%- if old_relation.is_view -%}
{%- call statement('main') -%}
{{ create_table_as(False, tmp_relation, sql) }}
{%- endcall -%}
{%- do drop_relation(old_relation) -%}
{%- do rename_relation(tmp_relation, target_relation) -%}
{%- else -%}

{%- if tmp_relation is not none -%}
{%- do drop_relation(tmp_relation) -%}
{%- endif -%}

{%- set old_relation_bkp = make_temp_relation(old_relation, '__bkp') -%}
-- If we have this, it means that at least the first renaming occurred but there was an issue
-- afterwards, therefore we are in weird state. The easiest and cleanest should be to remove
-- the backup relation. It won't have an impact because since we are in the else condition,
-- that means that old relation exists therefore no downtime yet.
{%- if old_relation_bkp is not none -%}
{%- do drop_relation(old_relation_bkp) -%}
{%- endif -%}

{%- call statement('main') -%}
{{ create_table_as(False, tmp_relation, sql) }}
{%- endcall -%}

{{ rename_relation(old_relation, old_relation_bkp) }}
{{ rename_relation(tmp_relation, target_relation) }}

{{ drop_relation(old_relation_bkp) }}
{%- endif -%}

{%- call statement('main') -%}
{{ create_table_as(False, tmp_relation, sql) }}
{%- endcall -%}

{{ rename_relation(old_relation, old_relation_bkp) }}
{{ rename_relation(tmp_relation, target_relation) }}

{{ drop_relation(old_relation_bkp) }}
{%- endif -%}

{%- endif -%}
Expand Down
26 changes: 26 additions & 0 deletions tests/functional/adapter/test_change_relation_types.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
import pytest

from dbt.tests.adapter.relations.test_changing_relation_type import (
BaseChangeRelationTypeValidator,
)


class TestChangeRelationTypesHive(BaseChangeRelationTypeValidator):
pass


class TestChangeRelationTypesIceberg(BaseChangeRelationTypeValidator):
@pytest.fixture(scope="class")
def project_config_update(self):
return {
"models": {
"+table_type": "iceberg",
}
}

def test_changing_materialization_changes_relation_type(self, project):
self._run_and_check_materialization("view")
self._run_and_check_materialization("table")
self._run_and_check_materialization("view")
# skip incremntal that doesn't work with Iceberg
self._run_and_check_materialization("table", extra_args=["--full-refresh"])