Custom `fabric__snapshot_merge_sql` is a 30-line UPDATE+INSERT pair — replace with native MERGE

[sdebruyn]

Summary

The adapter ships a custom fabric__snapshot_merge_sql that does an UPDATE statement followed by a separate INSERT statement, with an apply_label() helper call between them. dbt-core's default__snapshot_merge_sql produces a single MERGE statement that Fabric Warehouse supports natively. The custom override is unnecessary, produces non-atomic behaviour, and runs two statements where one suffices.

Evidence (HEAD 0de2190, v1.10.0)

dbt/include/fabric/macros/materializations/snapshots/snapshot_merge.sql defines fabric__snapshot_merge_sql as a 30-line UPDATE-then-INSERT pair.

User impact

• Two warehouse round-trips per snapshot run instead of one.
• Non-atomic semantics: a reader that lands between the UPDATE and the INSERT can see an inconsistent snapshot.
• More code to maintain in the adapter.

Suggested fix

Delete fabric__snapshot_merge_sql entirely and let dbt-core's default__snapshot_merge_sql (which uses MERGE) handle Fabric. Fabric Warehouse supports MERGE INTO with the standard ANSI syntax dbt-core emits.

This fix pairs naturally with the related proposal to centralise query labels via dbt-adapters' query_header. Once labelling happens at the connection-manager layer instead of per-statement Jinja, the only justification for the custom override (interleaving apply_label() between UPDATE and INSERT) disappears and the macro can simply be deleted.

Reference fix in the fork: commit 0857efc1 (combined deletion of fabric__snapshot_merge_sql and the apply_label() helper it relied on).

Happy to open a PR alongside if useful.