perf: apply only new or changed databricks_tags on table re-runs - #1572
Closed
sd-db wants to merge 5 commits into
Closed
perf: apply only new or changed databricks_tags on table re-runs#1572sd-db wants to merge 5 commits into
sd-db wants to merge 5 commits into
Conversation
Coverage report
Click to see where and how coverage changed
This report was generated by python-coverage-comment-action |
||||||||||||||||||||||||
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.
sd-db
changed the title
Collaborator
Author
|
/integration-test |
|
Integration tests dispatched for PR #1572 by @sd-db. Testing commit aa94d84. Track progress in the Actions tab. |
|
Integration results for PR #1572 — UC cluster ✅ success · SQL warehouse ✅ success · All-purpose cluster ✅ success · Shard coverage ✅ success |
Collaborator
Author
|
Closing this for now. The extra #1667 and #1668 are separate—they improve tag diffs where we already use changesets. This comment was generated with GitHub MCP. |
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
Table rebuilds and incremental full-refresh replacements reapply configured table and column tags even when those tags already match the server. This adds unnecessary
ALTER … SET TAGSstatements, particularly for models with many tagged columns.Root cause
Table rebuilds and incremental full-refresh replacements bypass the normal incremental ALTER changeset flow. Their creation paths therefore did not reuse the existing
TagsConfig.get_diffandColumnTagsConfig.get_diffcomparisons.Fix
reconcile_tagsacross the V1 and V2 Table and Incremental full-refresh paths.get_table_replacement_tag_changes, so Jinja can reuse the Python processors and component diffs without fetching unrelated relation configuration.incremental_apply_config_changes.This PR wires replacement paths into the existing component diffs; it does not introduce per-key filtering. At this head, a changed table tag can reapply the desired table-tag map, and a changed column can reapply that column's desired tags. Finer-grained table and column tag diffs are handled separately in #1667 and #1668.
Only tags are in scope; reconciliation of other metadata after replacement is unchanged.
Validation
information_schemaafter creation, unchanged full-refresh, and changed full-refresh to verify the stored tag values.Live replacement validation used Delta tables; managed Iceberg behavior was not verified.
Resolves #1308