fix: apply column_tags on V1 incremental materialization#1520
Merged
Conversation
sd-db
force-pushed
the
sd-db/fix/v1-incremental-column-tags
branch
from
ac5c07f to
0b556e3
Compare
V1 (use_materialization_v2=false, the default) incremental models silently dropped column-level databricks_tags: the V1 branch of incremental.sql never called apply_column_tags on create, on full-refresh/recreate, or in the merge configuration changeset, while V1 table create and the V2 path both apply them. Apply column tags on all three V1 incremental paths, mirroring table.sql and apply_config_changeset. Follow-up to #1307, which fixed the same gap for tables only. (Note: on Delta, full-refresh uses CREATE OR REPLACE which already preserves column tags, so that hunk is defensive/consistency; the observable bug was create + config-change.) Tests: TestColumnTagsIncrementalV1 (create + merge-change) and TestColumnTagsIncrementalV1FullRefresh in the column_tags functional suite; test_column_tags_macros.py pins the apply/alter render and the empty-diff no-op (idempotency).
sd-db
force-pushed
the
sd-db/fix/v1-incremental-column-tags
branch
from
0b556e3 to
ba11357
Compare
Coverage report
This PR does not seem to contain any modification to coverable code. |
Collaborator
Author
|
/integration-test |
|
Integration tests dispatched for PR #1520 by @sd-db. Track progress in the Actions tab. |
|
Integration results for PR #1520 — UC cluster ✅ success · SQL warehouse ❌ failure · All-purpose cluster ✅ success · Shard coverage ✅ success |
|
Integration results for PR #1520 — UC cluster ✅ success · SQL warehouse ✅ success · All-purpose cluster ✅ success · Shard coverage ✅ success |
jprakash-db
approved these changes
Jun 17, 2026
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.
Description
V1 (
use_materialization_v2: false, the default) incremental models silently dropped column-leveldatabricks_tags. The V1 branch ofincremental/incremental.sqlnever calledapply_column_tagson its create, full-refresh/recreate, or merge-changeset paths — while V1tablecreate (fixed in #1307) and the entire V2 path both apply them. The model builds successfully butsystem.information_schema.column_tagsstays empty, with no error or warning.This applies column tags on all three V1 incremental paths, mirroring
table.sqlandapply_config_changeset. Follow-up to #1307, which fixed the identical gap for thetablematerialization only.Tests
column_tags/test_column_tags.py::TestColumnTagsIncrementalV1— create (run 1) + merge-change (run 2); fails onmain, passes here.column_tags/test_column_tags.py::TestColumnTagsIncrementalV1FullRefresh— column tags survive adbt run --full-refresh.tests/unit/macros/relations/components/test_column_tags_macros.py—apply_column_tags/alter_set_column_tagsrender (incl. the view →ALTER TABLEspecial case) and the empty-diff no-op (idempotency).Checklist
### Fixes)