/ 
DBIO-MSSQL-0.900004
/ DBIO::MSSQL::Diff::PrimaryKey

NAME

DBIO::MSSQL::Diff::PrimaryKey - Diff operations for MSSQL primary keys

VERSION

version 0.900004

DESCRIPTION

Primary-key operations for tables that exist on both sides. The key of a new table is part of its CREATE TABLE (DBIO::MSSQL::Diff::Table); the key of a dropped table goes with it. The model carries no key object: it is read from the columns, is_pk and pk_position (the position in the key, so the order of a composite key counts), and the live name from pk_constraint_name (DBIO::MSSQL::Introspect::Columns).

A key that differs -- other columns, or the same columns in another order -- becomes a pair, because a table has one primary key and SQL Server refuses the second (measured):

ALTER TABLE t DROP CONSTRAINT <live name>;
ALTER TABLE t ADD CONSTRAINT PK_t PRIMARY KEY (a, b);

The name of a key the diff adds is PK_<table>, the one "install_ddl" in DBIO::MSSQL::DDL writes. The name of a key already in the database is not compared: the server named it, and two databases that hold the same key under different names are the same.

The key is compared as CLUSTERED or NONCLUSTERED as well (pk_clustered, DBIO::MSSQL::Introspect::Columns), when both models carry it: the classes create the key clustered, so a live nonclustered key is dropped and added again with the same columns, and the added key says CLUSTERED out loud -- without the word the server makes it nonclustered while a clustered index stands on the table, and the next diff would find the difference again (measured). The clustered index the live table may have beside a nonclustered key is no obstacle: the classes refuse a clustered index next to a key (Msg 1902), so the target has none, and the diff drops it (or re-creates it nonclustered) before the key is added.

A key is dropped and added again, without a difference in its columns, when one of its columns changes its type: the server refuses ALTER COLUMN to another type on a key column (a width change of nvarchar works), see "unbinds_dependents" in DBIO::MSSQL::Diff::Column.

A target without a key drops the live key (maintainer's decision, as DBIO::Sybase::Diff does, and as a foreign key the classes do not declare is dropped: what the classes do not declare does not stay). "summary" names it on a line of its own, PRIMARY KEY DROPPED. The server refuses to drop a key a foreign key references (measured), so the foreign keys that reference it are dropped first by DBIO::MSSQL::Diff; if the classes declare one of them, it could not be created afterwards (no primary or candidate key in the referenced table, measured) and the diff refuses with a DBIO::Exception naming table and foreign key instead of dropping a declared foreign key. A unique constraint or unique index over the same columns is a candidate key and lets the foreign key stand.

DBIO::MSSQL::Diff places the operations: the drops with the other drops before the column phase, the adds after it (a column that becomes the key has to be NOT NULL first, which the server demands), and it drops and adds the foreign keys that reference the key around it.

METHODS

diff

my @ops = DBIO::MSSQL::Diff::PrimaryKey->diff(
    $source_columns, $target_columns, $source_tables, $target_tables,
    \@column_ops);

as_sql

summary

AUTHOR

DBIO & DBIx::Class Authors

COPYRIGHT AND LICENSE

Copyright (C) 2026 DBIO Authors Portions Copyright (C) 2005-2025 DBIx::Class Authors Based on DBIx::Class, heavily modified.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.