Skip to content

docs(databricks): merge databricks_tags additively across config hierarchy levels#9379

Open
sd-db wants to merge 2 commits into
dbt-labs:currentfrom
sd-db:sd-db/docs-sync/pr-1340
Open

docs(databricks): merge databricks_tags additively across config hierarchy levels#9379
sd-db wants to merge 2 commits into
dbt-labs:currentfrom
sd-db:sd-db/docs-sync/pr-1340

Conversation

@sd-db

@sd-db sd-db commented Jun 10, 2026

Copy link
Copy Markdown
Contributor

What this PR does

Documents that databricks_tags now 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

  • Adds a "Breaking change in v1.12.0" caution callout with a worked example (project-level + model-level merge) in the databricks_tags section.
  • Notes the additive-merge behavior in the relevant footnotes (table and column config tables) with links back to the detailed section.
  • Clarifies the merge applies wherever databricks_tags is set — tables, columns, materialized views, and streaming tables.

Which audience does this affect?

dbt-databricks users on v1.12.0+ who set databricks_tags at more than one config hierarchy level.

…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 sd-db requested a review from a team as a code owner June 10, 2026 08:11
@vercel

vercel Bot commented Jun 10, 2026

Copy link
Copy Markdown

@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.

@github-actions github-actions Bot added the content Improvements or additions to content label Jun 10, 2026
@luna-bianca luna-bianca self-assigned this Jun 16, 2026
@vercel

vercel Bot commented Jun 17, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
docs-getdbt-com Ready Ready Preview Jun 17, 2026 11:30am

Request Review

@luna-bianca luna-bianca left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

content Improvements or additions to content

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants