fix: apply only new or changed databricks_tags on table re-runs - #1572
Open
sd-db wants to merge 3 commits into
Open
fix: apply only new or changed databricks_tags on table re-runs#1572sd-db wants to merge 3 commits into
sd-db wants to merge 3 commits into
Conversation
jprakash-db
approved these changes
Jul 8, 2026
Address review gaps on the table tag-diff change: - Assert a *changed* tag value still reaches the server on a re-run, for both table- and column-level tags. This is the diff path's one real failure mode and was previously uncovered; the existing tests only assert whether a metadata fetch occurred. - Add a v2 `create_table_at` case for table-level tags. v2 coverage was column-tags only, and `use_materialization_v2` defaults to false, so the unmarked classes all exercise v1. - Make `TestTableDropRecreateAppliesAllTags` rerun-safe. It rewrites a model via `write_file`, so without the mixin a `--reruns` retry inherits the converted table and stops testing view->table conversion. Also link the PR in the changelog entry and describe the diff's gating condition rather than naming file formats: `resolve_file_format` maps `table_format='iceberg'` to delta or parquet, so it does not return the literal 'iceberg' the gate tests for.
Resolves a conflict in `table.sql` between this branch's `replaced_in_place` refactor and #1592, which added `is_shallow_clone` to the two drop conditions that `replaced_in_place` negates. Since a shallow clone's table type cannot be changed in place, it must be dropped and recreated -- so it is not replaced in place and inherits no tags. Folded the term into the predicate rather than into the drop sites, keeping both as `not replaced_in_place`: replaced_in_place = existing_relation and not existing_relation.is_shallow_clone and existing_relation.type == 'table' and existing_relation.can_be_replaced and adapter.resolve_file_format(config) in ('delta', 'iceberg') `can_be_replaced` alone does not cover this: it tests relation type plus delta/iceberg provider, so a shallow clone of a delta table passes it. Add `TestRebuildOverShallowCloneAppliesAllTags`, which covers the interaction both changes touch: rebuilding a tagged table over a shallow clone must drop the clone and apply all tags to the fresh table. Without the `is_shallow_clone` term it fails on `MANAGED_SHALLOW_CLONE != MANAGED` -- i.e. it guards #1592's fix, not only the tag diff. Also move this branch's changelog entry to the 1.12.4 (TBD) section; the automatic merge placed it under the already-released 1.12.2 heading.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
For the
tablematerialization, dbt re-applies every configureddatabricks_tags(table-level) and column-leveldatabricks_tagson every run viaALTER … SET TAGS— oneALTERper column. When many columns are tagged this dominates run time (eachSET TAGSis ~300ms) even when nothing changed.Root cause
The set-only tag diff already exists (
TagsConfig.get_diff/ColumnTagsConfig.get_diff) but is wired only into the incremental materialization. Thetablepath applies all configured tags unconditionally on every run — both the v1/legacy path and the v2create_table_at.Fix
Reuse the existing diff on the table path. When an existing delta/iceberg table is replaced in place (
CREATE OR REPLACE, which preserves tags), fetch the current server tags and apply only those that are new or changed. Fresh creates and drop+recreates apply all tags (no tags to diff against), and tag-free models skip the fetch entirely.The diff is gated on
replaced_in_place— an existing delta/iceberg table replaced in place — not merely on a relation having existed. A drop+recreate (a non-table type, or a non-delta/iceberg format) produces a fresh table with no inherited tags, so it must apply all configured tags rather than diff against possibly-stale metadata.Tests
New
tests/functional/adapter/tags/test_table_tag_fetch_skips.py:Existing tag and incremental-metadata-fetch suites are unchanged and green.
Closes #1308