fix: deterministically name unnamed PK/FK so incremental constraints don't churn or collide

[sd-db]

What

Unnamed primary/foreign keys churned on every incremental run, and two or more unnamed foreign keys to the same parent failed with DELTA_CONSTRAINT_ALREADY_EXISTS. Databricks auto-names an unnamed key, so the model's name=None never matched the catalog read; the diff issued DROP CONSTRAINT ... CASCADE + re-add each run (silently dropping dependent FKs), and the unnamed FK re-adds collided on the server-derived <table>_<parent>_fk name.

Fix

dbt now assigns an unnamed PK/FK the same deterministic name its create-time macro already writes (synthesize_constraint_name), generated identically on the create and incremental paths, so the model and catalog agree and the diff is a no-op. A foreign key's name folds in its referenced columns (its full identity), so distinct FKs never collide — and a config that currently fails at create (two unnamed FKs from one column to different parent columns) becomes possible.

• No change to the diff key or get_diff — once names are deterministic, the existing (name, columns) comparison + repoint reconciliation just work.
• Macro↔Python name parity is pinned by TestConstraintNameParity so the two implementations can't drift while both exist.

Behavior

Existing unnamed foreign keys are renamed once on the next incremental run (a no-op DROP/re-add, no cascade), then stable — consistent with #1551 folding expression into the PK name in this same release. An unnamed key's expression/target edit is now reconciled (its name encodes it), unlike a named key (#1552 — still needs --full-refresh); the #1552 changelog note is scoped to named keys accordingly.

Tests

• Unit: name generator reproduces a live-captured macro hash; from_relation_config names unnamed PK/FK; get_diff no-ops for matched and two-FK-to-one-parent cases (with a negative assertion); macro↔Python parity for FK (single/multi/expression) and PK (incl. RELY); distinct to_columns → distinct names.
• Functional (UC SQL warehouse, use_materialization_v2: false): two unnamed FKs to one parent survive an incremental run (1.11.5 fails with DELTA_CONSTRAINT_ALREADY_EXISTS in incremental models with two or more foreign keys to same relation #1344); an unnamed RELY PK's dependent FK survives an incremental re-run (TABLE_OR_VIEW_NOT_FOUND on constraint DROP during V2 incremental materialization #1333 + [BUG]: Mismatch in PK & FK expression (e.g. RELY) triggers unnecessary constraint drops that crashes on incremental runs #1513). Both verified RED→GREEN on a live warehouse.

Supersedes #1554 (its unnamed-PK fix is reimplemented here more generally; its RELY-PK regression test is carried forward as an unnamed-PK variant).

Closes #1333
Closes #1344

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
dbt/adapters/databricks
constraints.py					187
dbt/adapters/databricks/relation_configs
constraints.py
Project Total

This report was generated by python-coverage-comment-action

[sd-db]

/integration-test

[github-actions]

Integration tests dispatched for PR #1561 by @sd-db. Track progress in the Actions tab.

[github-actions]

Integration results for PR #1561 — UC cluster ✅ success · SQL warehouse ❌ failure · All-purpose cluster ✅ success · Shard coverage ✅ success

Run details.