fix(fabric): drop leaked __dbt_tmp_vw helper view after CTAS#1011
Conversation
dbt-fabric's fabric__create_table_as implements CTAS via a helper view
`<table>__dbt_tmp_vw`: it creates the view, then issues
`CREATE TABLE <table> AS SELECT * FROM <table>__dbt_tmp_vw`. The macro
does NOT drop the helper view at the end — it relies on the caller
(dbt-fabric's own incremental / table materializations) to drop it via
`adapter.drop_relation` after the CTAS.
Elementary's edr_create_table_as does not perform that post-drop, so the
helper view leaks in the elementary schema every time edr_create_table_as
is invoked on Fabric. Affects every artifact table built this way:
dbt_columns, dbt_exposures, dbt_seeds, dbt_sources, dbt_tests, plus
their __tmp_<ts> intermediates from delete_and_insert. The leaked views
accumulate one entry per run and per artifact, eventually polluting the
schema.
Add a fabric__edr_get_create_table_as_sql dispatch implementation that
calls dbt.get_create_table_as_sql and appends
`EXEC('DROP VIEW IF EXISTS ...')` to the emitted SQL, so the helper view
is dropped in the same batch that consumed it. Uses IF EXISTS, so it is
safe even if a future dbt-fabric release decides to clean up the helper
view itself.
Upstream macro reference:
dbt-fabric/dbt/include/fabric/macros/materializations/models/table/create_table_as.sql
|
👋 @tderk |
tderk
requested a deployment
to
elementary_test_env
GitHub Actions
Waiting
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR adds a Fabric-specific CTAS macro implementation that extends dbt's standard ChangesFabric CTAS with Helper View Cleanup
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
dbt-fabric's fabric__create_table_as implements CTAS via a helper view
<table>__dbt_tmp_vw: it creates the view, then issuesCREATE TABLE <table> AS SELECT * FROM <table>__dbt_tmp_vw. The macro does NOT drop the helper view at the end — it relies on the caller (dbt-fabric's own incremental / table materializations) to drop it viaadapter.drop_relationafter the CTAS.Elementary's edr_create_table_as does not perform that post-drop, so the helper view leaks in the elementary schema every time edr_create_table_as is invoked on Fabric. Affects every artifact table built this way: dbt_columns, dbt_exposures, dbt_seeds, dbt_sources, dbt_tests, plus their _tmp intermediates from delete_and_insert. The leaked views accumulate one entry per run and per artifact, eventually polluting the schema.
Add a fabric__edr_get_create_table_as_sql dispatch implementation that calls dbt.get_create_table_as_sql and appends
EXEC('DROP VIEW IF EXISTS ...')to the emitted SQL, so the helper view is dropped in the same batch that consumed it. Uses IF EXISTS, so it is safe even if a future dbt-fabric release decides to clean up the helper view itself.Upstream macro reference:
dbt-fabric/dbt/include/fabric/macros/materializations/models/table/create_table_as.sql
Summary by CodeRabbit