You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
dbt-fabric materializes tables by first renaming the destination table by prefixing __dbt_backup. It then creates the new table using a CTAS statement or a CREATE TABLE followed by an INSERT INTO statement, if contract is being enforced.
Observed disadvantages:
Contract breakage: When a change breaks the contract, the backup table is not being renamed to the original name.
Downtime: The table is unavailable while the model is being rebuild. This is not a problem for small models, but for large models this means significant downtime in which any reports or applications using the model are going to fail.
Proposed change:
Change the materialization macro to build the model in a temporary table first.
Once the build is complete, swap the destination table with the temporary table.
This approach minimizes downtime to split seconds and avoids situations where the build fails and the destination table remains renamed.
Example Implementation:
My knowledge of dbt is limited, so I am sure that below example is far from best practice.
I only included it for illustration purposes.
{% set tmp_relation = relation.incorporate(path={"identifier": relation.identifier ~ '_temp_view'}, type='view')-%}
{% do adapter.drop_relation(tmp_relation)%}
{{ get_create_view_as_sql(tmp_relation, sql) }}
{% set contract_config = config.get('contract') %}
{% if contract_config.enforced %}
DROP TABLE IF EXISTS [{{relation.database}}].[{{relation.schema}}].[{{relation.identifier}}_temp];
CREATE TABLE [{{relation.database}}].[{{relation.schema}}].[{{relation.identifier}}_temp]
{{ fabric__build_columns_constraints(relation) }}
{{ get_assert_columns_equivalent(sql) }}
{% set listColumns %}
{% for column in model['columns'] %}
{{ "["~column~"]" }}{{ ", " if not loop.last }}
{% endfor %}
{%endset%}
INSERT INTO [{{relation.database}}].[{{relation.schema}}].[{{relation.identifier}}_temp]
({{listColumns}}) SELECT {{listColumns}} FROM [{{tmp_relation.database}}].[{{tmp_relation.schema}}].[{{tmp_relation.identifier}}];
DROP TABLE IF EXISTS [{{relation.database}}].[{{relation.schema}}].[{{relation.identifier}}];
EXEC sp_rename '[{{relation.database}}].[{{relation.schema}}].[{{relation.identifier}}_temp]', '{{relation.identifier}}';
{%- else %}
DROP TABLE IF EXISTS [{{relation.database}}].[{{relation.schema}}].[{{relation.identifier}}_temp];
EXEC('CREATE TABLE [{{relation.database}}].[{{relation.schema}}].[{{relation.identifier}}_temp] AS (SELECT * FROM [{{tmp_relation.database}}].[{{tmp_relation.schema}}].[{{tmp_relation.identifier}}]);');
IF EXISTS ( SELECT * FROM INFORMATION_SCHEMA.TABLES where TABLE_TYPE IN ( 'BASE TABLE','VIEW') and TABLE_SCHEMA = '{{relation.schema}}' AND TABLE_NAME ='{{relation.identifier}}' )
BEGIN
DROP TABLE IF EXISTS [{{relation.schema}}].{{relation.identifier}}_temp_old;
EXEC sp_rename '{{relation.schema}}.{{relation.identifier}}','{{relation.identifier}}_temp_old';
END
EXEC sp_rename '{{relation.schema}}.{{relation.identifier}}_temp', '{{relation.identifier}}';
IF EXISTS ( SELECT 1 FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE ='BASE TABLE' AND TABLE_NAME = '{{relation.identifier}}_temp_old' AND TABLE_SCHEMA = '{{relation.schema}}' )
BEGIN
DROP TABLE [{{relation.schema}}].{{relation.identifier}}_temp_old;
END
IF EXISTS (SELECT 1 FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_NAME = '{{relation.identifier}}_temp_old' AND TABLE_SCHEMA = '{{relation.schema}}' )
BEGIN
DROP VIEW [{{relation.schema}}].{{relation.identifier}}_temp_old;
END
{% endif %}
{% do adapter.drop_relation(tmp_relation)%}
{% endmacro %}
´´´
The text was updated successfully, but these errors were encountered:
Current behavior:
dbt-fabric materializes tables by first renaming the destination table by prefixing __dbt_backup. It then creates the new table using a CTAS statement or a CREATE TABLE followed by an INSERT INTO statement, if contract is being enforced.
Observed disadvantages:
Proposed change:
Change the materialization macro to build the model in a temporary table first.
Once the build is complete, swap the destination table with the temporary table.
This approach minimizes downtime to split seconds and avoids situations where the build fails and the destination table remains renamed.
Example Implementation:
My knowledge of dbt is limited, so I am sure that below example is far from best practice.
I only included it for illustration purposes.
´´´
{% macro fabric__create_table_as(temporary, relation, sql) -%}
{% endmacro %}
´´´
The text was updated successfully, but these errors were encountered: