docs(databricks): merge databricks_tags additively across config hierarchy levels#9379
Open
sd-db wants to merge 2 commits into
Open
docs(databricks): merge databricks_tags additively across config hierarchy levels#9379sd-db wants to merge 2 commits into
sd-db wants to merge 2 commits into
Conversation
…archy levels (databricks/dbt-databricks#1340) `databricks_tags` now merges additively across dbt config hierarchy levels: a model-level `databricks_tags` value no longer clobbers tags defined at the project level — instead the dictionaries are merged (child keys override matching parent keys, other parent keys are retained). This is a breaking change for projects that relied on lower-level configs fully replacing higher-level ones.
|
@sd-db is attempting to deploy a commit to the dbt-labs Team on Vercel. A member of the Team first needs to authorize it. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
luna-bianca
reviewed
Jun 17, 2026
luna-bianca
left a comment
Contributor
There was a problem hiding this comment.
Thanks for opening this PR, @sd-db ! I have some editorial suggestions, please check! Also, can you please add this update to Upgrade guide for 1.12? Thanks!
| † When `table_format` is `iceberg`, `file_format` must be `delta`. | ||
|
|
||
| ‡ `databricks_tags` are applied via `ALTER` statements. Tags cannot be removed via dbt-databricks once applied. To remove tags, use Databricks directly or a post-hook. | ||
| ‡ `databricks_tags` are applied via `ALTER` statements. Tags cannot be removed via dbt-databricks once applied. To remove tags, use Databricks directly or a post-hook. As of dbt-databricks v1.12.0, `databricks_tags` set at multiple config hierarchy levels [merge additively](#databricks_tags) rather than the lower level fully replacing the higher one. |
Contributor
There was a problem hiding this comment.
Suggested change
| ‡ `databricks_tags` are applied via `ALTER` statements. Tags cannot be removed via dbt-databricks once applied. To remove tags, use Databricks directly or a post-hook. As of dbt-databricks v1.12.0, `databricks_tags` set at multiple config hierarchy levels [merge additively](#databricks_tags) rather than the lower level fully replacing the higher one. | |
| ‡ `databricks_tags` are applied via `ALTER` statements. Tags cannot be removed via dbt-databricks once applied. To remove tags, use Databricks directly or a post-hook. Starting in `dbt-databricks` v1.12, `databricks_tags` set at multiple config hierarchy levels [merge additively](#databricks_tags) instead of the lower (more specific) level fully replacing the higher one. |
|
|
||
|
|
||
| † `databricks_tags` are applied via `ALTER` statements. Tags cannot be removed via dbt-databricks once applied. To remove tags, use Databricks directly or a post-hook. | ||
| † `databricks_tags` are applied via `ALTER` statements. Tags cannot be removed via dbt-databricks once applied. To remove tags, use Databricks directly or a post-hook. As of dbt-databricks v1.12.0, `databricks_tags` set at multiple config hierarchy levels [merge additively](#databricks_tags) rather than the lower level fully replacing the higher one. |
Contributor
There was a problem hiding this comment.
Suggested change
| † `databricks_tags` are applied via `ALTER` statements. Tags cannot be removed via dbt-databricks once applied. To remove tags, use Databricks directly or a post-hook. As of dbt-databricks v1.12.0, `databricks_tags` set at multiple config hierarchy levels [merge additively](#databricks_tags) rather than the lower level fully replacing the higher one. | |
| † `databricks_tags` are applied via `ALTER` statements. Tags cannot be removed via dbt-databricks once applied. To remove tags, use Databricks directly or a post-hook. Starting in `dbt-databricks` v1.12, `databricks_tags` set at multiple config hierarchy levels [merge additively](#databricks_tags) instead of the lower (more specific) level fully replacing the higher one. |
|
|
||
| Tags are applied via `ALTER` statements after the materialization is created. Once applied, tags cannot be removed through dbt-databricks configuration changes. To remove tags, you must use Databricks directly or a post-hook. | ||
|
|
||
| :::caution Breaking change in v1.12.0 |
Contributor
There was a problem hiding this comment.
Can we change this to the following so it's not too alarming/negative?
Suggested change
| :::caution Breaking change in v1.12.0 | |
| :::caution Behavior change in v1.12 |
| Tags are applied via `ALTER` statements after the materialization is created. Once applied, tags cannot be removed through dbt-databricks configuration changes. To remove tags, you must use Databricks directly or a post-hook. | ||
|
|
||
| :::caution Breaking change in v1.12.0 | ||
| As of dbt-databricks v1.12.0, `databricks_tags` set at different config hierarchy levels (for example, project-level and model-level) merge additively instead of the lower-level config completely replacing the higher-level one. Keys defined at the lower level override matching keys from the higher level, and any other keys from the higher level are retained. This applies wherever `databricks_tags` is set, including tables, columns, materialized views, and streaming tables. |
Contributor
There was a problem hiding this comment.
Suggested change
| As of dbt-databricks v1.12.0, `databricks_tags` set at different config hierarchy levels (for example, project-level and model-level) merge additively instead of the lower-level config completely replacing the higher-level one. Keys defined at the lower level override matching keys from the higher level, and any other keys from the higher level are retained. This applies wherever `databricks_tags` is set, including tables, columns, materialized views, and streaming tables. | |
| Starting in `dbt-databricks` v1.12.0, `databricks_tags` configurations are merged additively across config hierarchy levels (for example, project-level and model-level), rather than having lower-level configs completely replace higher-level ones. | |
| When the same tag key is defined at multiple levels, the lower-level value takes precedence. Tag keys defined only at higher levels are retained. | |
| This behavior applies anywhere `databricks_tags` can be configured, including tables, columns, materialized views, and streaming tables. |
|
|
||
| </File> | ||
|
|
||
| The model is tagged with `a: b` (kept from the project level), `c: model_value` (the model-level value overrides the project-level `c`), and `k: v` (added at the model level). |
Contributor
There was a problem hiding this comment.
Suggested change
| The model is tagged with `a: b` (kept from the project level), `c: model_value` (the model-level value overrides the project-level `c`), and `k: v` (added at the model level). | |
| The resulting tags are: | |
| - `a: b` — retained from the project level | |
| - `c: model_value` — the model-level value overrides the project-level `c` | |
| - `k: v` — added at the model level |
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
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.
What this PR does
Documents that
databricks_tagsnow merges additively across dbt config hierarchy levels as of dbt-databricks v1.12.0. Previously, a lower-level config (e.g. model-level) fully replaced a higher-level one (e.g. project-level); now the dictionaries are merged — keys defined at the lower level override matching keys from the higher level, and any other higher-level keys are retained.This documents the behavior change introduced in databricks/dbt-databricks#1340.
Changes
databricks_tagssection.databricks_tagsis set — tables, columns, materialized views, and streaming tables.Which audience does this affect?
dbt-databricks users on v1.12.0+ who set
databricks_tagsat more than one config hierarchy level.