dbt-sqlserver 1.11.1__tar.gz → 1.11.2rc1__tar.gz

{dbt_sqlserver-1.11.1/dbt_sqlserver.egg-info → dbt_sqlserver-1.11.2rc1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: dbt-sqlserver
-Version: 1.11.1
+Version: 1.11.2rc1
 Summary: A Microsoft SQL Server adapter plugin for dbt
 Author: Mikael Ene, Anders Swanson, Sam Debruyn, Cor Zuurmond, Cody Scott
 License: MIT
@@ -283,6 +283,108 @@ You can also set it per model:
 {{ config(materialized="table", as_columnstore=false) }}
 ```
 
+With `table_refresh_method: dml`, a schema change makes the refresh fall back to a rename-swap. On that run — and only that run — the scratch table is rebuilt the way this adapter builds every other table, so it carries the model's columnstore index, and under an enforced contract its `NOT NULL`s and inline constraints, into the swap. That run therefore executes the model's SQL twice — once for the `SELECT … INTO` that probes for the schema change, once for the rebuild — and builds the columnstore index once. Steady-state refreshes are unaffected and keep the single `SELECT … INTO`. A table that lost its columnstore index to this bug before you upgraded is not repaired automatically: its schema still matches, so it stays on the cheap path. To rebuild it, temporarily set `full_refresh_build: prebuilt` and run with `--full-refresh`.
+
+### Constraints
+
+Constraints declared in a model's yaml are applied when — and only when — the model's [contract](https://docs.getdbt.com/reference/resource-configs/contract) is enforced, which is what every dbt adapter does and keeps their cost opt-in. (dbt-core does not raise if you declare constraints with the contract off — they are simply never emitted.) `not_null`, `check`, `unique`, `primary_key` and `foreign_key` are all supported.
+
+**Where a constraint lands depends on whether you name it.**
+
+An unnamed constraint is rendered inline in the `CREATE TABLE` column list and SQL Server names it (`PK__my_model__3213E83F…`). It is validated as the table is built, so a violation fails before the new table is swapped in and the previous one is left untouched.
+
+A *model-level* constraint carrying `name:` is applied by `ALTER TABLE … ADD CONSTRAINT` after the build swaps the new table into place and drops the old one. SQL Server scopes constraint names per schema, and a table is built alongside the one it replaces, so that is the first moment the name is free to reuse — naming a constraint inline would collide with the outgoing table (`Msg 2714`) on every rebuild after the first. The trade-off is that this runs after the model has committed: if the data violates the constraint, the model fails with the table already in place but unconstrained, and — as with any failure this late in a build — `post_hook`s declared with `transaction: false` do not run.
+
+Name a constraint when you want it stable across environments (schema-comparison tools report the generated names as differences) or need to reference it later. A `name:` on a *column-level* constraint is ignored with a warning — declare it under the model's `constraints:` key instead.
+
+The full set of rules, with the test that verifies each, is in [docs/constraints.md](docs/constraints.md).
+
+```yaml
+models:
+  - name: fact_sales
+    config:
+      contract:
+        enforced: true
+    constraints:
+      # named: applied by ALTER TABLE after the swap
+      - type: primary_key
+        name: PK_fact_sales
+        columns: [sale_id]
+      - type: foreign_key
+        name: FK_fact_sales_customer
+        columns: [customer_id]
+        to: ref('dim_customer')
+        to_columns: [customer_id]
+      # unnamed: rendered into the CREATE TABLE
+      - type: check
+        expression: amount >= 0
+    columns:
+      - name: sale_id
+        data_type: int
+        constraints:
+          - type: not_null
+      - name: customer_id
+        data_type: int
+        constraints:
+          - type: not_null
+      - name: amount
+        data_type: decimal(18,2)
+```
+
+#### Clustering
+
+`primary_key` and `unique` are emitted as `NONCLUSTERED` by default so they can coexist with the clustered columnstore index built for [`as_columnstore`](#as_columnstore). Use dbt's own `expression` field to ask for something else:
+
+```yaml
+    constraints:
+      - type: primary_key
+        name: PK_fact_sales
+        columns: [sale_id]
+        expression: clustered   # requires as_columnstore: false
+```
+
+`clustered` and `nonclustered` are the only values understood here. `expression` is free text that dbt splices between the keyword and the column list, which is the one place T-SQL accepts nothing else — index options such as `with (fillfactor = 90)` belong on a separate index, not on the constraint.
+
+#### Foreign keys
+
+Two things are worth knowing before adding them:
+
+- **They are not free at build time.** Every load is validated against them; add them where you want the guarantee, not everywhere the relationship exists.
+- **A foreign key pointing at a model blocks that model's rebuild.** The build renames the outgoing table to a backup and drops it, but the child's foreign key follows the renamed object, so the drop fails with `Msg 3726`. SQL Server has no `DROP TABLE … CASCADE`.
+
+  The adapter ships a macro for exactly this, meant as a `pre_hook` on the **referenced** (parent) model:
+
+  ```sql
+  {{ config(pre_hook="{{ drop_fk_constraints() }}") }}
+  ```
+
+  It drops the foreign keys in both directions — the inbound ones other tables hold against this model, and this model's own outbound ones — so the rebuild's backup drop succeeds. The trade-off is explicit and worth stating: **the child's foreign key does not exist between the parent's rebuild and the child's next build.** (dbt-postgres makes the same trade silently, by issuing every `drop table` with `cascade`.)
+
+  Add the hook *before* the first rebuild. Once a rebuild has failed with `Msg 3726`, the new table is already in place but without its own named constraints — those are applied after the backup drop that failed — and the child's key now points at `<model>__dbt_backup`, because a foreign key follows the object, not the name. A plain `dbt run` does not recover: the parent trips over the same backup and the child is skipped behind it. Rebuild the child alone — that run fails too, since the parent has no key to reference, but its swap drops the old child and the stale key with it — and a plain `dbt run` then rebuilds both in order. Dropping the child's key by hand (`ALTER TABLE <child> DROP CONSTRAINT <name>`) does the same.
+
+  `table_refresh_method: dml` is *not* a workaround. Its steady-state refresh issues `DELETE FROM <parent>`, which fails with `Msg 547` as soon as the child holds referencing rows, and its schema-change path falls back to the same rename-swap, hitting `Msg 3726` anyway.
+
+- **SQL Server has no cross-database foreign keys.** `to: ref(...)` resolves to a fully qualified relation, database included, which SQL Server accepts as long as it names the current database. A target in another database fails with `references invalid table`.
+
+A foreign key also does not order the build on its own: add an explicit `-- depends_on: {{ ref('dim_customer') }}` to the child model so the parent is built first.
+
+#### Changing a constraint after the first build
+
+Named constraints are applied by an `ALTER TABLE` whose `ADD` is guarded on the name already being present on the table, so:
+
+- **Adding** a constraint to a model that already exists lands on its next run — no `--full-refresh` needed, on `table` and `incremental` alike.
+- **Changing** an existing constraint's definition while keeping its name is *not* detected: a constraint name, unlike a `dbt_idx_` index name, says nothing about what the constraint does. Run `--full-refresh` to apply the new definition; that rebuilds the table, so the constraint is created fresh. (A `table` model rebuilds on every run and needs nothing special.)
+- **Renaming** a constraint on a table that persists across runs adds the new name beside the old one. For a `check`, `unique` or `foreign_key` that means a duplicate; for a `primary_key` the run fails with `Msg 1779` (*table already has a primary key defined on it*) until the old one is dropped. Rename with `--full-refresh`.
+- **Removing** a constraint from the yaml does not drop it from the database. Drop it yourself, or `--full-refresh`.
+
+Every bullet above is about *named* constraints. Unnamed ones ride the `CREATE TABLE`, so they follow the table and change only when the table is rebuilt — on a materialization whose table persists across runs (`incremental` in its steady state, `table_refresh_method: dml`), adding an unnamed constraint to an existing model does nothing until a `--full-refresh`, and the run still reports success. Name it, or full-refresh.
+
+#### Build-shape notes
+
+An *unnamed* `primary_key` or `unique` constraint on a column that also carries a [data mask](#dynamic-data-masking-masked_with--masks) is rejected by the build. The constraint rides the `CREATE TABLE`, so its index already exists by the time `apply_masks` runs, and the adapter refuses to mask any column that an index has as a key: *is configured for masking but is also an index key column*. Declare that constraint at the model level **with a `name:`** instead — named constraints are applied by `ALTER TABLE` after the masks are in place, which the adapter allows.
+
+A contract-enforced model is always loaded as `CREATE TABLE` followed by `INSERT … WITH (TABLOCK)`, on every build path. A `primary_key` or `unique` constraint — named or not — puts a nonclustered index on that table *before* the load, so the index is maintained row by row while the rows go in, and that part of the load is fully logged where an index-free heap would have been minimally logged. The cost lands on every rebuild of the model; it is most visible with `full_refresh_build: prebuilt`, whose point is a cheap bulk load. If a model's load time matters, weigh the key constraints against it; `check`, `not_null` and `foreign_key` do not create indexes and do not carry this cost.
+
 ### Dynamic Data Masking (`masked_with` / `masks`)
 
 The adapter can apply SQL Server [Dynamic Data Masking](https://learn.microsoft.com/en-us/sql/relational-databases/security/dynamic-data-masking) (DDM) to columns as part of the materialization, so masks are re-applied on every build and survive dbt's drop-and-recreate on a full refresh. A principal granted `SELECT` but not `UNMASK` then sees masked values instead of real data (dbt's own build principal, being `db_owner`, keeps `UNMASK` and reads real data). Requires **SQL Server 2016+**.

{dbt_sqlserver-1.11.1 → dbt_sqlserver-1.11.2rc1}/README.md

@@ -246,6 +246,108 @@ You can also set it per model:
 {{ config(materialized="table", as_columnstore=false) }}
 ```
 
+With `table_refresh_method: dml`, a schema change makes the refresh fall back to a rename-swap. On that run — and only that run — the scratch table is rebuilt the way this adapter builds every other table, so it carries the model's columnstore index, and under an enforced contract its `NOT NULL`s and inline constraints, into the swap. That run therefore executes the model's SQL twice — once for the `SELECT … INTO` that probes for the schema change, once for the rebuild — and builds the columnstore index once. Steady-state refreshes are unaffected and keep the single `SELECT … INTO`. A table that lost its columnstore index to this bug before you upgraded is not repaired automatically: its schema still matches, so it stays on the cheap path. To rebuild it, temporarily set `full_refresh_build: prebuilt` and run with `--full-refresh`.
+
+### Constraints
+
+Constraints declared in a model's yaml are applied when — and only when — the model's [contract](https://docs.getdbt.com/reference/resource-configs/contract) is enforced, which is what every dbt adapter does and keeps their cost opt-in. (dbt-core does not raise if you declare constraints with the contract off — they are simply never emitted.) `not_null`, `check`, `unique`, `primary_key` and `foreign_key` are all supported.
+
+**Where a constraint lands depends on whether you name it.**
+
+An unnamed constraint is rendered inline in the `CREATE TABLE` column list and SQL Server names it (`PK__my_model__3213E83F…`). It is validated as the table is built, so a violation fails before the new table is swapped in and the previous one is left untouched.
+
+A *model-level* constraint carrying `name:` is applied by `ALTER TABLE … ADD CONSTRAINT` after the build swaps the new table into place and drops the old one. SQL Server scopes constraint names per schema, and a table is built alongside the one it replaces, so that is the first moment the name is free to reuse — naming a constraint inline would collide with the outgoing table (`Msg 2714`) on every rebuild after the first. The trade-off is that this runs after the model has committed: if the data violates the constraint, the model fails with the table already in place but unconstrained, and — as with any failure this late in a build — `post_hook`s declared with `transaction: false` do not run.
+
+Name a constraint when you want it stable across environments (schema-comparison tools report the generated names as differences) or need to reference it later. A `name:` on a *column-level* constraint is ignored with a warning — declare it under the model's `constraints:` key instead.
+
+The full set of rules, with the test that verifies each, is in [docs/constraints.md](docs/constraints.md).
+
+```yaml
+models:
+  - name: fact_sales
+    config:
+      contract:
+        enforced: true
+    constraints:
+      # named: applied by ALTER TABLE after the swap
+      - type: primary_key
+        name: PK_fact_sales
+        columns: [sale_id]
+      - type: foreign_key
+        name: FK_fact_sales_customer
+        columns: [customer_id]
+        to: ref('dim_customer')
+        to_columns: [customer_id]
+      # unnamed: rendered into the CREATE TABLE
+      - type: check
+        expression: amount >= 0
+    columns:
+      - name: sale_id
+        data_type: int
+        constraints:
+          - type: not_null
+      - name: customer_id
+        data_type: int
+        constraints:
+          - type: not_null
+      - name: amount
+        data_type: decimal(18,2)
+```
+
+#### Clustering
+
+`primary_key` and `unique` are emitted as `NONCLUSTERED` by default so they can coexist with the clustered columnstore index built for [`as_columnstore`](#as_columnstore). Use dbt's own `expression` field to ask for something else:
+
+```yaml
+    constraints:
+      - type: primary_key
+        name: PK_fact_sales
+        columns: [sale_id]
+        expression: clustered   # requires as_columnstore: false
+```
+
+`clustered` and `nonclustered` are the only values understood here. `expression` is free text that dbt splices between the keyword and the column list, which is the one place T-SQL accepts nothing else — index options such as `with (fillfactor = 90)` belong on a separate index, not on the constraint.
+
+#### Foreign keys
+
+Two things are worth knowing before adding them:
+
+- **They are not free at build time.** Every load is validated against them; add them where you want the guarantee, not everywhere the relationship exists.
+- **A foreign key pointing at a model blocks that model's rebuild.** The build renames the outgoing table to a backup and drops it, but the child's foreign key follows the renamed object, so the drop fails with `Msg 3726`. SQL Server has no `DROP TABLE … CASCADE`.
+
+  The adapter ships a macro for exactly this, meant as a `pre_hook` on the **referenced** (parent) model:
+
+  ```sql
+  {{ config(pre_hook="{{ drop_fk_constraints() }}") }}
+  ```
+
+  It drops the foreign keys in both directions — the inbound ones other tables hold against this model, and this model's own outbound ones — so the rebuild's backup drop succeeds. The trade-off is explicit and worth stating: **the child's foreign key does not exist between the parent's rebuild and the child's next build.** (dbt-postgres makes the same trade silently, by issuing every `drop table` with `cascade`.)
+
+  Add the hook *before* the first rebuild. Once a rebuild has failed with `Msg 3726`, the new table is already in place but without its own named constraints — those are applied after the backup drop that failed — and the child's key now points at `<model>__dbt_backup`, because a foreign key follows the object, not the name. A plain `dbt run` does not recover: the parent trips over the same backup and the child is skipped behind it. Rebuild the child alone — that run fails too, since the parent has no key to reference, but its swap drops the old child and the stale key with it — and a plain `dbt run` then rebuilds both in order. Dropping the child's key by hand (`ALTER TABLE <child> DROP CONSTRAINT <name>`) does the same.
+
+  `table_refresh_method: dml` is *not* a workaround. Its steady-state refresh issues `DELETE FROM <parent>`, which fails with `Msg 547` as soon as the child holds referencing rows, and its schema-change path falls back to the same rename-swap, hitting `Msg 3726` anyway.
+
+- **SQL Server has no cross-database foreign keys.** `to: ref(...)` resolves to a fully qualified relation, database included, which SQL Server accepts as long as it names the current database. A target in another database fails with `references invalid table`.
+
+A foreign key also does not order the build on its own: add an explicit `-- depends_on: {{ ref('dim_customer') }}` to the child model so the parent is built first.
+
+#### Changing a constraint after the first build
+
+Named constraints are applied by an `ALTER TABLE` whose `ADD` is guarded on the name already being present on the table, so:
+
+- **Adding** a constraint to a model that already exists lands on its next run — no `--full-refresh` needed, on `table` and `incremental` alike.
+- **Changing** an existing constraint's definition while keeping its name is *not* detected: a constraint name, unlike a `dbt_idx_` index name, says nothing about what the constraint does. Run `--full-refresh` to apply the new definition; that rebuilds the table, so the constraint is created fresh. (A `table` model rebuilds on every run and needs nothing special.)
+- **Renaming** a constraint on a table that persists across runs adds the new name beside the old one. For a `check`, `unique` or `foreign_key` that means a duplicate; for a `primary_key` the run fails with `Msg 1779` (*table already has a primary key defined on it*) until the old one is dropped. Rename with `--full-refresh`.
+- **Removing** a constraint from the yaml does not drop it from the database. Drop it yourself, or `--full-refresh`.
+
+Every bullet above is about *named* constraints. Unnamed ones ride the `CREATE TABLE`, so they follow the table and change only when the table is rebuilt — on a materialization whose table persists across runs (`incremental` in its steady state, `table_refresh_method: dml`), adding an unnamed constraint to an existing model does nothing until a `--full-refresh`, and the run still reports success. Name it, or full-refresh.
+
+#### Build-shape notes
+
+An *unnamed* `primary_key` or `unique` constraint on a column that also carries a [data mask](#dynamic-data-masking-masked_with--masks) is rejected by the build. The constraint rides the `CREATE TABLE`, so its index already exists by the time `apply_masks` runs, and the adapter refuses to mask any column that an index has as a key: *is configured for masking but is also an index key column*. Declare that constraint at the model level **with a `name:`** instead — named constraints are applied by `ALTER TABLE` after the masks are in place, which the adapter allows.
+
+A contract-enforced model is always loaded as `CREATE TABLE` followed by `INSERT … WITH (TABLOCK)`, on every build path. A `primary_key` or `unique` constraint — named or not — puts a nonclustered index on that table *before* the load, so the index is maintained row by row while the rows go in, and that part of the load is fully logged where an index-free heap would have been minimally logged. The cost lands on every rebuild of the model; it is most visible with `full_refresh_build: prebuilt`, whose point is a cheap bulk load. If a model's load time matters, weigh the key constraints against it; `check`, `not_null` and `foreign_key` do not create indexes and do not carry this cost.
+
 ### Dynamic Data Masking (`masked_with` / `masks`)
 
 The adapter can apply SQL Server [Dynamic Data Masking](https://learn.microsoft.com/en-us/sql/relational-databases/security/dynamic-data-masking) (DDM) to columns as part of the materialization, so masks are re-applied on every build and survive dbt's drop-and-recreate on a full refresh. A principal granted `SELECT` but not `UNMASK` then sees masked values instead of real data (dbt's own build principal, being `db_owner`, keeps `UNMASK` and reads real data). Requires **SQL Server 2016+**.

dbt_sqlserver-1.11.2rc1/dbt/adapters/sqlserver/__version__.py

@@ -0,0 +1 @@
+version = "1.11.2rc1"

{dbt_sqlserver-1.11.1 → dbt_sqlserver-1.11.2rc1}/dbt/adapters/sqlserver/sqlserver_adapter.py

@@ -42,6 +42,13 @@ from dbt.adapters.sqlserver.sqlserver_runtime import _get_pyodbc
 
 logger = AdapterLogger("SQLServer")
 
+# The constraint types this adapter renders itself rather than deferring to
+# dbt-adapters: each needs SQL Server's CLUSTERED/NONCLUSTERED choice or its
+# own column quoting.
+_KEYED_CONSTRAINTS = frozenset(
+    {ConstraintType.unique, ConstraintType.primary_key, ConstraintType.foreign_key}
+)
+
 # Mirrors sqlserver__select_starts_with_cte
 # (dbt/include/sqlserver/macros/adapters/columns.sql): a query opening with a
 # CTE cannot be neutered as ``select * from (...) where 1 = 0``, so it reaches
@@ -470,48 +477,219 @@ class SQLServerAdapter(SQLAdapter):
         finally:
             conn.transaction_open = False
 
+    @classmethod
+    def _clustering(cls, keyword: str, expression: str) -> str:
+        """Render a PRIMARY KEY / UNIQUE keyword with its index clustering.
+
+        SQL Server defaults an unqualified PRIMARY KEY to CLUSTERED, which is
+        incompatible with the clustered columnstore index the adapter builds
+        for ``as_columnstore`` (the default), so NONCLUSTERED is the safe
+        default here. dbt's own ``expression`` field is the override - a
+        constraint declaring ``expression: clustered`` keeps what it asked for
+        - so no adapter-specific yaml key is needed.
+
+        Those two keywords are the only thing T-SQL accepts in this position,
+        so anything else is rejected here rather than emitted as DDL that
+        cannot parse.
+        """
+        clustering = expression.strip()
+        if not clustering:
+            return f"{keyword} {SQLServerIndexType.default()}"
+        if clustering.lower() not in (
+            SQLServerIndexType.clustered,
+            SQLServerIndexType.nonclustered,
+        ):
+            raise dbt_common.exceptions.DbtValidationError(
+                f"Invalid expression '{expression}' on a {keyword} constraint. "
+                f"SQL Server accepts only '{SQLServerIndexType.clustered}' or "
+                f"'{SQLServerIndexType.nonclustered}' here; index options belong on a "
+                "separate index, not on the constraint."
+            )
+        return f"{keyword} {clustering}"
+
+    @classmethod
+    def _render_foreign_key_target(cls, constraint: ColumnLevelConstraint) -> Optional[str]:
+        """The ``references <table> (<columns>)`` tail of a foreign key.
+
+        Accepts both the ``to`` / ``to_columns`` form and the older free-text
+        ``expression`` form; returns None when neither is usable.
+
+        dbt-core resolves ``to: ref(...)`` to a fully rendered relation, which
+        for this adapter includes the database. That three-part name is passed
+        through as-is: SQL Server resolves it fine while it names the current
+        database, and a genuinely cross-database target - which SQL Server does
+        not support for foreign keys - then fails with its own clear "references
+        invalid table" error rather than being silently rewritten to point at a
+        same-named table in this database.
+        """
+        if constraint.to and constraint.to_columns:
+            columns = ", ".join(cls.quote(column) for column in constraint.to_columns)
+            return f"references {constraint.to} ({columns})"
+        if constraint.expression:
+            return f"references {constraint.expression}"
+        logger.warning(
+            f"Dropping the {constraint.type.value} constraint"
+            + (f" '{constraint.name}'" if constraint.name else "")
+            + ": it names no target. Declare `to:` together with `to_columns:`, "
+            "or the free-text `expression:` form (`<table> (<columns>)`)."
+        )
+        return None
+
+    @classmethod
+    def _render_keyed_constraint(
+        cls, constraint: ColumnLevelConstraint, column_list: str = ""
+    ) -> Optional[str]:
+        """The constraint types this adapter renders differently from dbt-adapters.
+
+        Shared by the column-level and model-level renderers, which differ only
+        in whether they name their columns: a column-level constraint is written
+        against the column it follows, a model-level one carries its own list.
+        """
+        expression = constraint.expression or ""
+        suffix = f" ({column_list})" if column_list else ""
+
+        if constraint.type == ConstraintType.unique:
+            return cls._clustering("unique", expression) + suffix
+        if constraint.type == ConstraintType.primary_key:
+            return cls._clustering("primary key", expression) + suffix
+        target = cls._render_foreign_key_target(constraint)
+        if target is None:
+            return None
+        return f"foreign key ({column_list}) {target}" if column_list else target
+
     @available
     @classmethod
     def render_column_constraint(cls, constraint: ColumnLevelConstraint) -> Optional[str]:
-        rendered_column_constraint = None
-        if constraint.type == ConstraintType.not_null:
-            rendered_column_constraint = "not null "
-        else:
-            rendered_column_constraint = ""
+        """Render a column-level constraint inline in the CREATE TABLE column list.
+
+        Column-level constraints are always anonymous: the table is built as
+        ``<model>__dbt_tmp`` while the previous one still exists, and SQL
+        Server scopes constraint names per schema, so a name reused across
+        builds collides (Msg 2714). Declare the constraint at the model level
+        to name it - those are applied by ALTER after the swap, where the old
+        name is already gone.
+
+        Only UNIQUE, PRIMARY KEY and FOREIGN KEY need SQL Server treatment; NOT
+        NULL, CHECK and CUSTOM fall through to dbt-adapters so they stay in step
+        with upstream.
+        """
+        if constraint.name:
+            logger.warning(
+                f"Ignoring the name '{constraint.name}' on the column-level "
+                f"{constraint.type.value} constraint: SQL Server scopes constraint names "
+                "per schema, so naming one inline collides with the table being replaced. "
+                "Declare the constraint under the model's `constraints:` key to name it."
+            )
+
+        if constraint.type in _KEYED_CONSTRAINTS:
+            return cls._render_keyed_constraint(constraint)
+        return super().render_column_constraint(constraint)
 
-        if rendered_column_constraint:
-            rendered_column_constraint = rendered_column_constraint.strip()
+    @available
+    @classmethod
+    def render_raw_columns_constraints(
+        cls, raw_columns: Dict[str, Dict[str, Any]], only_not_null: bool = False
+    ) -> List[str]:
+        """Render the column DDL for a CREATE TABLE column list.
+
+        A fork of the dbt-adapters loop of the same name, for two reasons.
+        CHECK constraints are hoisted out of the column definition and returned
+        as standalone table-level clauses: SQL Server accepts only one
+        column-level CHECK per column ("More than one column CHECK constraint
+        specified for column ..."), while the table-level form has no such
+        limit. Both are anonymous and both live inside the same CREATE TABLE.
+
+        ``only_not_null`` drops everything but NOT NULL, for the unit-test
+        fixture tables: their rows are hand-written stand-ins for the model's
+        data, so a UNIQUE, PRIMARY KEY or FOREIGN KEY copied off the contract
+        would fail the unit test on data that was never meant to satisfy it.
+        """
+        rendered_columns = []
+        table_level_clauses = []
+
+        for column in raw_columns.values():
+            name = cls.quote(column["name"]) if column.get("quote") else column["name"]
+            parts = [f"{name} {column['data_type']}"]
+            for raw_constraint in column.get("constraints") or []:
+                constraint = cls._parse_column_constraint(raw_constraint)
+                if only_not_null and constraint.type != ConstraintType.not_null:
+                    continue
+                clause = cls.process_parsed_constraint(constraint, cls.render_column_constraint)
+                if not clause:
+                    continue
+                if constraint.type == ConstraintType.check:
+                    table_level_clauses.append(clause)
+                else:
+                    parts.append(clause)
+            rendered_columns.append(" ".join(parts))
 
-        return rendered_column_constraint
+        return rendered_columns + table_level_clauses
 
     @classmethod
     def render_model_constraint(cls, constraint: ModelLevelConstraint) -> Optional[str]:
-        constraint_prefix = "add constraint "
-        column_list = ", ".join(constraint.columns)
-
-        if constraint.name is None:
-            raise dbt_common.exceptions.DbtDatabaseError(
-                "Constraint name cannot be empty. Provide constraint name  - column "
-                + column_list
-                + " and run the project again."
-            )
+        """Render an unnamed model-level constraint inline in the column list.
 
-        if constraint.type == ConstraintType.unique:
-            return constraint_prefix + f"{constraint.name} unique nonclustered({column_list})"
-        elif constraint.type == ConstraintType.primary_key:
-            return constraint_prefix + f"{constraint.name} primary key nonclustered({column_list})"
-        elif constraint.type == ConstraintType.foreign_key and constraint.expression:
-            return (
-                constraint_prefix
-                + f"{constraint.name} foreign key({column_list}) references "
-                + constraint.expression
-            )
-        elif constraint.type == ConstraintType.check and constraint.expression:
-            return f"{constraint_prefix} {constraint.name} check ({constraint.expression})"
-        elif constraint.type == ConstraintType.custom and constraint.expression:
-            return f"{constraint_prefix} {constraint.name} {constraint.expression}"
-        else:
+        A named one renders nothing here and is applied afterwards by
+        ``render_raw_model_alter_constraints`` instead - see
+        ``sqlserver__build_model_constraints``. Its ``expression`` is still
+        validated now: the ALTER runs after the build has committed and swapped
+        the table in, and a typo there should fail before any of that happens.
+        """
+        if constraint.name:
+            if constraint.type in (ConstraintType.unique, ConstraintType.primary_key):
+                cls._clustering(
+                    constraint.type.value.replace("_", " "), constraint.expression or ""
+                )
             return None
+        return cls._render_model_constraint_body(constraint)
+
+    @available
+    @classmethod
+    def render_raw_model_alter_constraints(
+        cls, raw_constraints: List[Dict[str, Any]]
+    ) -> List[Dict[str, str]]:
+        """The *named* model constraints, as ``{name, clause}`` pairs.
+
+        ``clause`` is an ``add constraint <name> ...`` tail for ALTER TABLE;
+        ``name`` is the bare name, which the macro needs as a string literal to
+        test ``sys.objects`` before adding it. These are applied once the build
+        has swapped the new table into place and dropped the old one, which is
+        the only point at which the name is free to reuse.
+        """
+        clauses = []
+        for raw_constraint in raw_constraints:
+            constraint = cls._parse_model_constraint(raw_constraint)
+            if not constraint.name:
+                continue
+            body = cls.process_parsed_constraint(constraint, cls._render_model_constraint_body)
+            if body:
+                clauses.append(
+                    {
+                        "name": constraint.name,
+                        "clause": f"add constraint {cls.quote(constraint.name)} {body}",
+                    }
+                )
+        return clauses
+
+    @classmethod
+    def _render_model_constraint_body(cls, constraint: ModelLevelConstraint) -> Optional[str]:
+        """The constraint itself, without any name - valid both in a CREATE
+        TABLE column list and after ``ALTER TABLE ... ADD CONSTRAINT <name>``.
+
+        The base renderer cannot stand in here: it prefixes ``constraint
+        <name>`` whenever the constraint is named, which the ALTER form already
+        carries.
+        """
+        expression = constraint.expression or ""
+
+        if constraint.type in _KEYED_CONSTRAINTS:
+            column_list = ", ".join(cls.quote(column) for column in constraint.columns)
+            return cls._render_keyed_constraint(constraint, column_list)
+        if constraint.type == ConstraintType.check and expression:
+            return f"check ({expression})"
+        if constraint.type == ConstraintType.custom and expression:
+            return expression
+        return None
 
     def _get_row_count(self, relation) -> int:
         """Return the number of rows in the given relation."""

{dbt_sqlserver-1.11.1 → dbt_sqlserver-1.11.2rc1}/dbt/include/sqlserver/macros/materializations/models/incremental/incremental.sql

@@ -189,6 +189,10 @@
       {% do adapter.drop_relation(rel) %}
   {% endfor %}
 
+  {#-- Named model-level constraints. After the to_drop loop, so the backup no
+       longer holds the old names. See sqlserver__build_model_constraints. --#}
+  {{ build_model_constraints(target_relation) }}
+
   {{ run_hooks(post_hooks, inside_transaction=False) }}
 
   {{ return({'relations': [target_relation]}) }}

dbt_sqlserver-1.11.2rc1/dbt/include/sqlserver/macros/materializations/models/table/columns_spec_ddl.sql

@@ -0,0 +1,79 @@
+{% macro build_columns_constraints(relation, only_not_null=False) %}
+    {{ return(adapter.dispatch('build_columns_constraints', 'dbt')(relation, only_not_null)) }}
+{% endmacro %}
+
+{% macro sqlserver__build_columns_constraints(relation, only_not_null=False) %}
+  {#- The parenthesised column list for CREATE TABLE. Carries every column-level
+      constraint plus the *unnamed* model-level ones: both are anonymous, so
+      SQL Server names them itself and nothing collides with the table this
+      build is about to replace. Named model-level constraints are applied
+      afterwards by build_model_constraints. -#}
+    {%- set raw_column_constraints = adapter.render_raw_columns_constraints(
+        raw_columns=model['columns'], only_not_null=only_not_null) -%}
+    {%- set raw_model_constraints = [] if only_not_null
+        else adapter.render_raw_model_constraints(
+            raw_constraints=model.get('constraints') or []) -%}
+    (
+      {% for c in raw_column_constraints + raw_model_constraints -%}
+        {{ c }}{{ "," if not loop.last }}
+      {% endfor %}
+    )
+{% endmacro %}
+
+{% macro build_model_constraints(relation) %}
+    {{ return(adapter.dispatch('build_model_constraints', 'dbt')(relation)) }}
+{% endmacro %}
+
+{% macro sqlserver__build_model_constraints(relation) %}
+  {#- Named model-level constraints, applied once the build has swapped the new
+      table into place and dropped the old one: SQL Server scopes constraint
+      names per schema, so the name is only free to reuse after the table that
+      held it is gone.
+
+      Each ADD is guarded on the name already being present on this table, so
+      the macro is safe to call on every build path, including the ones that
+      keep the existing table (a plain incremental run, a DML refresh). That
+      makes a constraint added to an existing model land on the next run rather
+      than waiting for a full refresh.
+
+      What the guard cannot see is a constraint whose *definition* changed under
+      an unchanged name: unlike an index name (a hash of its definition), a
+      constraint name says nothing about what the constraint does. Redefining
+      one needs --full-refresh, which rebuilds the table and so applies the new
+      definition to a table that carries none. This is documented in the README.
+
+      Emitted as a single batch: one round trip regardless of how many
+      constraints the model declares. -#}
+  {%- set contract_config = config.get('contract') -%}
+  {%- if not contract_config or not contract_config.enforced -%}
+    {{ return('') }}
+  {%- endif -%}
+
+  {%- set constraints = adapter.render_raw_model_alter_constraints(
+      raw_constraints=model.get('constraints') or []) -%}
+  {%- if not constraints -%}
+    {{ return('') }}
+  {%- endif -%}
+
+  {%- set object_id_literal = escape_single_quotes(relation.include(database=False)) -%}
+  {%- set alter_sql -%}
+    {{ get_use_database_sql(relation.database) }}
+    {%- for constraint in constraints %}
+    if not exists (
+      select 1
+      from sys.objects {{ information_schema_hints() }}
+      where name = '{{ escape_single_quotes(constraint['name']) }}'
+        and parent_object_id = OBJECT_ID('{{ object_id_literal }}')
+    )
+    begin
+      alter table {{ relation.include(database=False) }} {{ constraint['clause'] }};
+    end
+    {%- endfor %}
+  {%- endset %}
+
+  {#- auto_begin=False: this runs after the materialization's adapter.commit(),
+      so opening the ambient transaction here would leave one dangling. -#}
+  {% call statement('alter_table_add_constraints', auto_begin=False) -%}
+    {{ alter_sql }}
+  {%- endcall %}
+{% endmacro %}

{dbt_sqlserver-1.11.1 → dbt_sqlserver-1.11.2rc1}/dbt/include/sqlserver/macros/materializations/models/table/table.sql

@@ -126,6 +126,10 @@
     {{ drop_relation_if_exists(backup_relation) }}
   {% endif %}
 
+  {#-- Named model-level constraints, on every build path; guarded, so a no-op
+       where they already exist. See sqlserver__build_model_constraints. --#}
+  {{ build_model_constraints(target_relation) }}
+
   {{ run_hooks(post_hooks, inside_transaction=False) }}
 
   {{ return({'relations': [target_relation]}) }}

{dbt_sqlserver-1.11.1 → dbt_sqlserver-1.11.2rc1}/dbt/include/sqlserver/macros/materializations/models/table/table_dml_refresh.sql

@@ -110,6 +110,40 @@
     {%- set backup_relation = make_backup_relation(target_relation, backup_relation_type) -%}
     {{ drop_relation_if_exists(backup_relation) }}
 
+    {#- The scratch table above came from SELECT * INTO, which is the right
+        shape for the schema probe and the wrong one for the object that is
+        about to be renamed into position: it copies no constraint and no
+        index, and takes nullability from the query rather than from a
+        contract. Left as-is it silently strips the model of its clustered
+        columnstore index - create_indexes only builds what the `indexes`
+        config names, never the as_columnstore CCI - and, under a contract, of
+        its NOT NULLs and inline constraints too. None of it came back on a
+        later run, because every later run matched the new schema and took the
+        DELETE+INSERT path above.
+
+        So rebuild it the way this adapter builds every other table. The
+        rebuild belongs on this branch alone: doing it up front would build,
+        and then throw away, a full columnstore index on every steady-state
+        refresh, which on a large table dominates the run. A schema change is
+        rare, so one extra build here is much the cheaper trade.
+
+        It is not free, though: the model's SQL runs a second time here, the
+        SELECT * INTO above having already run it once as the schema probe.
+        Any side effect in that SQL therefore happens twice, and the two runs
+        are not interchangeable - the schema decision came from the first, the
+        table renamed into position comes from the second. A model whose column
+        shape can differ between them lands the second shape unchecked, unless
+        a contract is enforced and create_table_as re-asserts it. Probing the
+        tmp view instead of the materialized scratch would collapse the two
+        back into one, at the cost of changing how the probe behaves - a
+        separate change, not this one.
+
+        create_table_as builds and drops its own __dbt_tmp_vw. -#}
+    {{ drop_relation_if_exists(refresh_relation) }}
+    {% call statement('dml_refresh_rebuild') -%}
+      {{ get_create_table_as_sql(False, refresh_relation, sql) }}
+    {%- endcall %}
+
     {# Rename scratch table into position #}
     {% set existing_relation = load_cached_relation(target_relation) %}
     {% if existing_relation is not none %}
@@ -118,7 +152,7 @@
 
     {{ adapter.rename_relation(refresh_relation, target_relation) }}
 
-    {# Rebuilt via SELECT INTO (no masks carried), so apply masks before
+    {# Freshly rebuilt (no masks carried), so apply masks before
        create_indexes — a mask cannot be added to a column an index depends
        on (documented for all SQL Server versions). #}
     {% do apply_masks(target_relation, mask_config) %}

{dbt_sqlserver-1.11.1 → dbt_sqlserver-1.11.2rc1}/dbt/include/sqlserver/macros/materializations/models/unit_test/unit_test_create_table_as.sql

@@ -32,7 +32,11 @@
     {%- elif not is_nested_cte and contract_config.enforced %}
 
         CREATE TABLE {{relation}}
-        {{ build_columns_constraints(relation) }}
+        {#- only_not_null: the fixture rows are hand-written stand-ins for the
+            model's real data, so a UNIQUE / PRIMARY KEY / FOREIGN KEY copied
+            off the contract would fail the unit test on data that was never
+            meant to satisfy it. -#}
+        {{ build_columns_constraints(relation, only_not_null=True) }}
         {{ get_assert_columns_equivalent(sql)  }}
 
         {% set listColumns %}

{dbt_sqlserver-1.11.1 → dbt_sqlserver-1.11.2rc1}/dbt/include/sqlserver/macros/materializations/models/view/view.sql

@@ -69,7 +69,21 @@
       {% endif %}
     {% endif %}
     {% if should_skip_view_update %}
-      {% set build_sql = 'declare @dbt_sqlserver_noop int;' %}
+      {#- The view's SQL text is unchanged, so the CREATE/ALTER is skipped -
+          but a *referenced* table can still have changed shape (columns
+          added, dropped, or reordered) since this view was last built. SQL
+          Server resolves an unqualified `select *` at CREATE/ALTER time and
+          caches the result; skipping that statement here means the cached
+          column list silently goes stale relative to the underlying table,
+          even though this view's own definition never changed. sp_refreshview
+          re-derives that cached metadata from the table's current shape
+          without re-running the CREATE, so a skip stays a skip (no DDL, no
+          grant/deny churn) while the view keeps reporting the right columns. -#}
+      {#- sp_refreshview resolves its argument in the *current* database, so this needs
+          the same USE prefix every other name-resolving statement here carries -
+          without it a cross-database view model would refresh nothing and error. -#}
+      {% set object_name = "quotename('" ~ target_relation.schema ~ "') + '.' + quotename('" ~ target_relation.identifier ~ "')" %}
+      {% set build_sql = get_use_database_sql(target_relation.database) ~ " declare @dbt_sqlserver_refresh_target nvarchar(max) = " ~ object_name ~ "; exec sp_refreshview @dbt_sqlserver_refresh_target;" %}
     {% else %}
       {% set build_sql = get_create_view_as_sql(target_relation, sql) %}
     {% endif %}

{dbt_sqlserver-1.11.1 → dbt_sqlserver-1.11.2rc1/dbt_sqlserver.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: dbt-sqlserver
-Version: 1.11.1
+Version: 1.11.2rc1
 Summary: A Microsoft SQL Server adapter plugin for dbt
 Author: Mikael Ene, Anders Swanson, Sam Debruyn, Cor Zuurmond, Cody Scott
 License: MIT
@@ -283,6 +283,108 @@ You can also set it per model:
 {{ config(materialized="table", as_columnstore=false) }}
 ```
 
+With `table_refresh_method: dml`, a schema change makes the refresh fall back to a rename-swap. On that run — and only that run — the scratch table is rebuilt the way this adapter builds every other table, so it carries the model's columnstore index, and under an enforced contract its `NOT NULL`s and inline constraints, into the swap. That run therefore executes the model's SQL twice — once for the `SELECT … INTO` that probes for the schema change, once for the rebuild — and builds the columnstore index once. Steady-state refreshes are unaffected and keep the single `SELECT … INTO`. A table that lost its columnstore index to this bug before you upgraded is not repaired automatically: its schema still matches, so it stays on the cheap path. To rebuild it, temporarily set `full_refresh_build: prebuilt` and run with `--full-refresh`.
+
+### Constraints
+
+Constraints declared in a model's yaml are applied when — and only when — the model's [contract](https://docs.getdbt.com/reference/resource-configs/contract) is enforced, which is what every dbt adapter does and keeps their cost opt-in. (dbt-core does not raise if you declare constraints with the contract off — they are simply never emitted.) `not_null`, `check`, `unique`, `primary_key` and `foreign_key` are all supported.
+
+**Where a constraint lands depends on whether you name it.**
+
+An unnamed constraint is rendered inline in the `CREATE TABLE` column list and SQL Server names it (`PK__my_model__3213E83F…`). It is validated as the table is built, so a violation fails before the new table is swapped in and the previous one is left untouched.
+
+A *model-level* constraint carrying `name:` is applied by `ALTER TABLE … ADD CONSTRAINT` after the build swaps the new table into place and drops the old one. SQL Server scopes constraint names per schema, and a table is built alongside the one it replaces, so that is the first moment the name is free to reuse — naming a constraint inline would collide with the outgoing table (`Msg 2714`) on every rebuild after the first. The trade-off is that this runs after the model has committed: if the data violates the constraint, the model fails with the table already in place but unconstrained, and — as with any failure this late in a build — `post_hook`s declared with `transaction: false` do not run.
+
+Name a constraint when you want it stable across environments (schema-comparison tools report the generated names as differences) or need to reference it later. A `name:` on a *column-level* constraint is ignored with a warning — declare it under the model's `constraints:` key instead.
+
+The full set of rules, with the test that verifies each, is in [docs/constraints.md](docs/constraints.md).
+
+```yaml
+models:
+  - name: fact_sales
+    config:
+      contract:
+        enforced: true
+    constraints:
+      # named: applied by ALTER TABLE after the swap
+      - type: primary_key
+        name: PK_fact_sales
+        columns: [sale_id]
+      - type: foreign_key
+        name: FK_fact_sales_customer
+        columns: [customer_id]
+        to: ref('dim_customer')
+        to_columns: [customer_id]
+      # unnamed: rendered into the CREATE TABLE
+      - type: check
+        expression: amount >= 0
+    columns:
+      - name: sale_id
+        data_type: int
+        constraints:
+          - type: not_null
+      - name: customer_id
+        data_type: int
+        constraints:
+          - type: not_null
+      - name: amount
+        data_type: decimal(18,2)
+```
+
+#### Clustering
+
+`primary_key` and `unique` are emitted as `NONCLUSTERED` by default so they can coexist with the clustered columnstore index built for [`as_columnstore`](#as_columnstore). Use dbt's own `expression` field to ask for something else:
+
+```yaml
+    constraints:
+      - type: primary_key
+        name: PK_fact_sales
+        columns: [sale_id]
+        expression: clustered   # requires as_columnstore: false
+```
+
+`clustered` and `nonclustered` are the only values understood here. `expression` is free text that dbt splices between the keyword and the column list, which is the one place T-SQL accepts nothing else — index options such as `with (fillfactor = 90)` belong on a separate index, not on the constraint.
+
+#### Foreign keys
+
+Two things are worth knowing before adding them:
+
+- **They are not free at build time.** Every load is validated against them; add them where you want the guarantee, not everywhere the relationship exists.
+- **A foreign key pointing at a model blocks that model's rebuild.** The build renames the outgoing table to a backup and drops it, but the child's foreign key follows the renamed object, so the drop fails with `Msg 3726`. SQL Server has no `DROP TABLE … CASCADE`.
+
+  The adapter ships a macro for exactly this, meant as a `pre_hook` on the **referenced** (parent) model:
+
+  ```sql
+  {{ config(pre_hook="{{ drop_fk_constraints() }}") }}
+  ```
+
+  It drops the foreign keys in both directions — the inbound ones other tables hold against this model, and this model's own outbound ones — so the rebuild's backup drop succeeds. The trade-off is explicit and worth stating: **the child's foreign key does not exist between the parent's rebuild and the child's next build.** (dbt-postgres makes the same trade silently, by issuing every `drop table` with `cascade`.)
+
+  Add the hook *before* the first rebuild. Once a rebuild has failed with `Msg 3726`, the new table is already in place but without its own named constraints — those are applied after the backup drop that failed — and the child's key now points at `<model>__dbt_backup`, because a foreign key follows the object, not the name. A plain `dbt run` does not recover: the parent trips over the same backup and the child is skipped behind it. Rebuild the child alone — that run fails too, since the parent has no key to reference, but its swap drops the old child and the stale key with it — and a plain `dbt run` then rebuilds both in order. Dropping the child's key by hand (`ALTER TABLE <child> DROP CONSTRAINT <name>`) does the same.
+
+  `table_refresh_method: dml` is *not* a workaround. Its steady-state refresh issues `DELETE FROM <parent>`, which fails with `Msg 547` as soon as the child holds referencing rows, and its schema-change path falls back to the same rename-swap, hitting `Msg 3726` anyway.
+
+- **SQL Server has no cross-database foreign keys.** `to: ref(...)` resolves to a fully qualified relation, database included, which SQL Server accepts as long as it names the current database. A target in another database fails with `references invalid table`.
+
+A foreign key also does not order the build on its own: add an explicit `-- depends_on: {{ ref('dim_customer') }}` to the child model so the parent is built first.
+
+#### Changing a constraint after the first build
+
+Named constraints are applied by an `ALTER TABLE` whose `ADD` is guarded on the name already being present on the table, so:
+
+- **Adding** a constraint to a model that already exists lands on its next run — no `--full-refresh` needed, on `table` and `incremental` alike.
+- **Changing** an existing constraint's definition while keeping its name is *not* detected: a constraint name, unlike a `dbt_idx_` index name, says nothing about what the constraint does. Run `--full-refresh` to apply the new definition; that rebuilds the table, so the constraint is created fresh. (A `table` model rebuilds on every run and needs nothing special.)
+- **Renaming** a constraint on a table that persists across runs adds the new name beside the old one. For a `check`, `unique` or `foreign_key` that means a duplicate; for a `primary_key` the run fails with `Msg 1779` (*table already has a primary key defined on it*) until the old one is dropped. Rename with `--full-refresh`.
+- **Removing** a constraint from the yaml does not drop it from the database. Drop it yourself, or `--full-refresh`.
+
+Every bullet above is about *named* constraints. Unnamed ones ride the `CREATE TABLE`, so they follow the table and change only when the table is rebuilt — on a materialization whose table persists across runs (`incremental` in its steady state, `table_refresh_method: dml`), adding an unnamed constraint to an existing model does nothing until a `--full-refresh`, and the run still reports success. Name it, or full-refresh.
+
+#### Build-shape notes
+
+An *unnamed* `primary_key` or `unique` constraint on a column that also carries a [data mask](#dynamic-data-masking-masked_with--masks) is rejected by the build. The constraint rides the `CREATE TABLE`, so its index already exists by the time `apply_masks` runs, and the adapter refuses to mask any column that an index has as a key: *is configured for masking but is also an index key column*. Declare that constraint at the model level **with a `name:`** instead — named constraints are applied by `ALTER TABLE` after the masks are in place, which the adapter allows.
+
+A contract-enforced model is always loaded as `CREATE TABLE` followed by `INSERT … WITH (TABLOCK)`, on every build path. A `primary_key` or `unique` constraint — named or not — puts a nonclustered index on that table *before* the load, so the index is maintained row by row while the rows go in, and that part of the load is fully logged where an index-free heap would have been minimally logged. The cost lands on every rebuild of the model; it is most visible with `full_refresh_build: prebuilt`, whose point is a cheap bulk load. If a model's load time matters, weigh the key constraints against it; `check`, `not_null` and `foreign_key` do not create indexes and do not carry this cost.
+
 ### Dynamic Data Masking (`masked_with` / `masks`)
 
 The adapter can apply SQL Server [Dynamic Data Masking](https://learn.microsoft.com/en-us/sql/relational-databases/security/dynamic-data-masking) (DDM) to columns as part of the materialization, so masks are re-applied on every build and survive dbt's drop-and-recreate on a full refresh. A principal granted `SELECT` but not `UNMASK` then sees masked values instead of real data (dbt's own build principal, being `db_owner`, keeps `UNMASK` and reads real data). Requires **SQL Server 2016+**.

dbt_sqlserver-1.11.1/dbt/adapters/sqlserver/__version__.py

@@ -1 +0,0 @@
-version = "1.11.1"

dbt_sqlserver-1.11.1/dbt/include/sqlserver/macros/materializations/models/table/columns_spec_ddl.sql

@@ -1,30 +0,0 @@
-{% macro build_columns_constraints(relation) %}
-    {{ return(adapter.dispatch('build_columns_constraints', 'dbt')(relation)) }}
-{% endmacro %}
-
-{% macro sqlserver__build_columns_constraints(relation) %}
-  {# loop through user_provided_columns to create DDL with data types and constraints #}
-    {%- set raw_column_constraints = adapter.render_raw_columns_constraints(raw_columns=model['columns']) -%}
-    (
-      {% for c in raw_column_constraints -%}
-        {{ c }}{{ "," if not loop.last }}
-      {% endfor %}
-    )
-{% endmacro %}
-
-{% macro build_model_constraints(relation) %}
-    {{ return(adapter.dispatch('build_model_constraints', 'dbt')(relation)) }}
-{% endmacro %}
-
-{% macro sqlserver__build_model_constraints(relation) %}
-  {# loop through user_provided_columns to create DDL with data types and constraints #}
-    {%- set raw_model_constraints = adapter.render_raw_model_constraints(raw_constraints=model['constraints']) -%}
-    {% for c in raw_model_constraints -%}
-      {% set alter_table_script %}
-        alter table {{ relation.include(database=False) }} {{c}};
-      {%endset%}
-      {% call statement('alter_table_add_constraint') -%}
-        {{alter_table_script}}
-      {%- endcall %}
-    {% endfor -%}
-{% endmacro %}