• Prevents data loss when changing SQL Server column type/length
• Uses ALTER COLUMN instead of destructive DROP+ADD operations
• Properly handles DEFAULT constraints around ALTER COLUMN operations
• Preserves existing behavior for IDENTITY and computed column changes

Implement ALTER COLUMN for SQL Server type changes

• Refactored column change logic to distinguish between destructive changes and type/length changes
• Added requiresRecreation flag for IDENTITY and computed column changes only
• Implemented ALTER COLUMN path with DEFAULT constraint handling for type/length changes
• Properly drops and restores DEFAULT constraints before and after ALTER COLUMN operations

src/driver/sqlserver/SqlServerQueryRunner.ts

Add test entity for issue 3357

• Created test entity with id and name columns
• Name column has varchar(50) length constraint for testing length changes

test/github-issues/3357/entity/TestEntity.ts

Add integration test for column alteration

• Added integration test verifying data preservation on column length changes
• Tests ALTER COLUMN behavior across postgres, mysql, mssql, and cockroachdb
• Validates that existing data is preserved after column alteration
• Confirms column definition is updated to new length specification

test/github-issues/3357/issue-3357.ts

Description

SqlServerQueryRunner.changeColumn() now drops/re-adds DEFAULT constraints inside the new
typeOrLengthChanged branch, but the method still also performs default/rename-default operations
later. When type/length changes are combined with default addition/removal/change, this produces
invalid SQL (e.g., dropping the same constraint twice or adding an already-existing constraint),
breaking schema sync/migration generation.

Code

src/driver/sqlserver/SqlServerQueryRunner.ts[R1367-1451]

+            if (typeOrLengthChanged) {
+                // Use ALTER COLUMN to preserve data instead of DROP + ADD
+                // SQL Server supports: ALTER TABLE t ALTER COLUMN col_name new_type [NULL | NOT NULL]
+                // Drop default constraint first if one exists (SQL Server requires this before ALTER COLUMN)
+                if (
+                    oldColumn.default !== null &&
+                    oldColumn.default !== undefined
+                ) {
+                    const defaultName =
+                        this.dataSource.namingStrategy.defaultConstraintName(
+                            table,
+                            oldColumn.name,
+                        )
+                    upQueries.push(
+                        new Query(
+                            `ALTER TABLE ${this.escapePath(
+                                table,
+                            )} DROP CONSTRAINT "${defaultName}"`,
+                        ),
+                    )
+                    downQueries.push(
+                        new Query(
+                            `ALTER TABLE ${this.escapePath(
+                                table,
+                            )} ADD CONSTRAINT "${defaultName}" DEFAULT ${oldColumn.default} FOR "${oldColumn.name}"`,
+                        ),
+                    )
+                }
+
+                // Build ALTER COLUMN using the current (old) column name since rename hasn't run yet
+                const alterColumnForType = newColumn.clone()
+                alterColumnForType.name = oldColumn.name
+
+                upQueries.push(
+                    new Query(
+                        `ALTER TABLE ${this.escapePath(
+                            table,
+                        )} ALTER COLUMN ${this.buildCreateColumnSql(
+                            table,
+                            alterColumnForType,
+                            true,
+                            false,
+                            true,
+                        )}`,
+                    ),
+                )
+                downQueries.push(
+                    new Query(
+                        `ALTER TABLE ${this.escapePath(
+                            table,
+                        )} ALTER COLUMN ${this.buildCreateColumnSql(
+                            table,
+                            oldColumn,
+                            true,
+                            false,
+                            true,
+                        )}`,
+                    ),
+                )
+
+                // Restore default constraint after type change (use old name — rename hasn't run yet)
+                if (
+                    newColumn.default !== null &&
+                    newColumn.default !== undefined
+                ) {
+                    const defaultName =
+                        this.dataSource.namingStrategy.defaultConstraintName(
+                            table,
+                            oldColumn.name,
+                        )
+                    upQueries.push(
+                        new Query(
+                            `ALTER TABLE ${this.escapePath(
+                                table,
+                            )} ADD CONSTRAINT "${defaultName}" DEFAULT ${newColumn.default} FOR "${oldColumn.name}"`,
+                        ),
+                    )
+                    downQueries.push(
+                        new Query(
+                            `ALTER TABLE ${this.escapePath(
+                                table,
+                            )} DROP CONSTRAINT "${defaultName}"`,
+                        ),
+                    )
+                }

Evidence

In the new type/length-change path, the code unconditionally emits DEFAULT constraint DDL around
ALTER COLUMN (drop old default if present; add new default if present). Later in the same method,
defaults are still handled again via the existing if (newColumn.default !== oldColumn.default)
block. This creates concrete failing sequences:

- **Default removed + type/length changed**: the new branch drops the old default (1367-1394) and
does not re-add it; later, the existing default-change block sees `newColumn.default !==
oldColumn.default` and tries to drop the old default constraint again (2006-2023), which will fail
because it was already dropped.
- **Default added + type/length changed**: the new branch adds the new default constraint
(1427-1451) and later the existing default-change block will add it again (2035-2052), failing
because the constraint already exists.

Additionally, the rename-default-constraints logic runs based on oldColumn.default (1710-1759) and
assumes the old default constraint still exists; with the new early drop in the type/length branch,
rename-time drop/add can target a constraint that was already removed, or reintroduce an old default
even when the new schema removes it (until later blocks attempt to correct it).

src/driver/sqlserver/SqlServerQueryRunner.ts[1335-1452]
src/driver/sqlserver/SqlServerQueryRunner.ts[1688-1759]
src/driver/sqlserver/SqlServerQueryRunner.ts[2006-2061]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`SqlServerQueryRunner.changeColumn()` now manages DEFAULT constraints in two separate places:
1) inside the new `typeOrLengthChanged` ALTER COLUMN path
2) later via the existing default-change and rename-default logic

When type/length changes are combined with default add/remove/change, SQL can attempt to DROP or ADD the same default constraint twice, causing SQL Server errors.

## Issue Context
SQL Server requires dropping DEFAULT constraints before `ALTER COLUMN`, but the drop/re-add needs to be coordinated with existing logic that already handles default changes and rename-time default constraint updates.

## Fix Focus Areas
- src/driver/sqlserver/SqlServerQueryRunner.ts[1367-1451]
- src/driver/sqlserver/SqlServerQueryRunner.ts[1710-1759]
- src/driver/sqlserver/SqlServerQueryRunner.ts[2006-2061]

## Implementation notes
- Ensure the old default constraint is dropped exactly once before `ALTER COLUMN`.
- Ensure the default constraint is added exactly once after the type/length change, in a way that correctly handles:
 - default unchanged (drop+re-add same default)
 - default removed (drop only; do not re-add)
 - default added/changed (drop old if existed, then add new)
- Avoid rename-default operations assuming a dropped constraint still exists; either:
 - defer default re-creation until after rename/default-change logic runs, or
 - track a flag like `droppedDefaultForAlterColumn` and conditionally skip later drops/adds that would duplicate work.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

This PR adds the regression test only under test/github-issues/3357 rather than the functional
test suite, without any clear justification in the code. This violates the guideline to keep issue
fixes in test/functional to avoid per-issue test sprawl.

Code

test/github-issues/3357/issue-3357.ts[R10-73]

+describe("github issues > #3357 migration generation drops and creates columns instead of altering", () => {
+    let connections: DataSource[]
+
+    before(async () => {
+        connections = await createTestingConnections({
+            entities: [__dirname + "/entity/*{.js,.ts}"],
+            enabledDrivers: ["postgres", "mysql", "mssql", "cockroachdb"],
+            schemaCreate: true,
+            dropSchema: true,
+        })
+    })
+    beforeEach(() => reloadTestingDatabases(connections))
+    after(() => closeTestingConnections(connections))
+
+    it("should use ALTER COLUMN instead of DROP+ADD when changing column length to preserve data", () =>
+        Promise.all(
+            connections.map(async (connection) => {
+                const queryRunner = connection.createQueryRunner()
+
+                try {
+                    // Insert test data
+                    await queryRunner.manager.query(
+                        `INSERT INTO "test_entity" ("name") VALUES ('test-value')`,
+                    )
+
+                    const table = await queryRunner.getTable("test_entity")
+                    const nameColumn = table!.findColumnByName("name")!
+
+                    // Change length from 50 to 100
+                    const newColumn = nameColumn.clone()
+                    newColumn.length = "100"
+
+                    const sqlsInMemory =
+                        await queryRunner.getMemorySql()
+                    sqlsInMemory.upQueries = []
+                    sqlsInMemory.downQueries = []
+
+                    await queryRunner.changeColumn(table!, nameColumn, newColumn)
+
+                    // Verify no DROP COLUMN was generated
+                    const allSqls = [
+                        ...sqlsInMemory.upQueries,
+                    ]
+                        .map((q) => q.query)
+                        .join(" ")
+
+                    // allSqls.should.not.contain("DROP COLUMN") - this is hard to test without spying
+                    // Instead verify data is preserved
+                    const rows = await queryRunner.query(
+                        `SELECT "name" FROM "test_entity"`,
+                    )
+                    rows.should.have.length(1)
+                    rows[0].name.should.equal("test-value")
+
+                    // Verify the column was actually changed
+                    const updatedTable = await queryRunner.getTable("test_entity")
+                    const updatedColumn = updatedTable!.findColumnByName("name")!
+                    updatedColumn.length.should.equal("100")
+                } finally {
+                    await queryRunner.release()
+                }
+            }),
+        ))
+})

Evidence

Compliance ID 3 requires issue fix tests to be added/updated in test/functional and considers it a
failure when tests are added only under test/github-issues without a clear reason; this PR
introduces only test/github-issues/3357/issue-3357.ts for the fix.

Rule 3: Prefer functional tests over per-issue tests
test/github-issues/3357/issue-3357.ts[10-73]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The regression test for #3357 was added under `test/github-issues/3357`, but compliance requires issue fixes to live in the functional test suite unless there is a clear reason.
## Issue Context
Per-project compliance, prefer `test/functional` coverage to avoid accumulating per-issue tests.
## Fix Focus Areas
- test/github-issues/3357/issue-3357.ts[10-73]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new test file imports TableColumn but never uses it, adding noise and potentially failing
linting. This violates the requirement to avoid unnecessary/AI-like clutter in changes.

Code

test/github-issues/3357/issue-3357.ts[R2-3]

+import { DataSource } from "../../../src/data-source/DataSource"
+import { TableColumn } from "../../../src/schema-builder/table/TableColumn"

Evidence

Compliance ID 4 requires removing AI-generated noise and avoiding unnecessary additions;
TableColumn is newly imported but not referenced anywhere in the added test file.

Rule 4: Remove AI-generated noise
test/github-issues/3357/issue-3357.ts[2-3]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`TableColumn` is imported but never used in the new test.
## Issue Context
This adds noise and may fail lint/ts checks.
## Fix Focus Areas
- test/github-issues/3357/issue-3357.ts[2-3]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The PR changes SQL Server migration generation behavior (switching to ALTER COLUMN and handling
default constraints), which is user-visible, but no documentation or samples are updated in the
provided diff. This can leave users unaware of behavioral changes or limitations.

Code

src/driver/sqlserver/SqlServerQueryRunner.ts[R1367-1445]

+            if (typeOrLengthChanged) {
+                // Use ALTER COLUMN to preserve data instead of DROP + ADD
+                // SQL Server supports: ALTER TABLE t ALTER COLUMN col_name new_type [NULL | NOT NULL]
+                // Drop default constraint first if one exists (SQL Server requires this before ALTER COLUMN)
+                if (
+                    oldColumn.default !== null &&
+                    oldColumn.default !== undefined
+                ) {
+                    const defaultName =
+                        this.dataSource.namingStrategy.defaultConstraintName(
+                            table,
+                            oldColumn.name,
+                        )
+                    upQueries.push(
+                        new Query(
+                            `ALTER TABLE ${this.escapePath(
+                                table,
+                            )} DROP CONSTRAINT "${defaultName}"`,
+                        ),
+                    )
+                    downQueries.push(
+                        new Query(
+                            `ALTER TABLE ${this.escapePath(
+                                table,
+                            )} ADD CONSTRAINT "${defaultName}" DEFAULT ${oldColumn.default} FOR "${oldColumn.name}"`,
+                        ),
+                    )
+                }
+
+                upQueries.push(
+                    new Query(
+                        `ALTER TABLE ${this.escapePath(
+                            table,
+                        )} ALTER COLUMN ${this.buildCreateColumnSql(
+                            table,
+                            newColumn,
+                            true,
+                            false,
+                        )}`,
+                    ),
+                )
+                downQueries.push(
+                    new Query(
+                        `ALTER TABLE ${this.escapePath(
+                            table,
+                        )} ALTER COLUMN ${this.buildCreateColumnSql(
+                            table,
+                            oldColumn,
+                            true,
+                            false,
+                        )}`,
+                    ),
+                )
+
+                // Restore default constraint after type change
+                if (
+                    newColumn.default !== null &&
+                    newColumn.default !== undefined
+                ) {
+                    const defaultName =
+                        this.dataSource.namingStrategy.defaultConstraintName(
+                            table,
+                            newColumn.name,
+                        )
+                    upQueries.push(
+                        new Query(
+                            `ALTER TABLE ${this.escapePath(
+                                table,
+                            )} ADD CONSTRAINT "${defaultName}" DEFAULT ${newColumn.default} FOR "${newColumn.name}"`,
+                        ),
+                    )
+                    downQueries.push(
+                        new Query(
+                            `ALTER TABLE ${this.escapePath(
+                                table,
+                            )} DROP CONSTRAINT "${defaultName}"`,
+                        ),
+                    )
+                }

Evidence

Compliance ID 2 requires docs updates for user-facing changes; the diff shows a user-facing behavior
change in MSSQL DDL generation but contains no accompanying documentation updates.

Rule 2: Docs updated for user-facing changes
src/driver/sqlserver/SqlServerQueryRunner.ts[1367-1445]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
SQL Server migration generation behavior changed (type/length changes now use `ALTER COLUMN` with default constraint drop/re-add), but no docs/samples were updated in this PR.
## Issue Context
This is a user-visible change in generated migrations and may warrant documentation or release notes.
## Fix Focus Areas
- src/driver/sqlserver/SqlServerQueryRunner.ts[1367-1445]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new type/length-change path can emit an ALTER COLUMN, and the existing isColumnChanged() branch
can emit a second ALTER COLUMN in the same changeColumn call when other properties (e.g.,
precision/scale/nullability/collation) also differ.

Code

src/driver/sqlserver/SqlServerQueryRunner.ts[R1354-1419]

+        // Pure type/length changes can use ALTER COLUMN to preserve data
+        const typeOrLengthChanged =
+            newColumn.type !== oldColumn.type ||
+            newColumn.length !== oldColumn.length
+
+        if (requiresRecreation) {
+            // Must drop and recreate for identity/computed column changes
          await this.dropColumn(table, oldColumn)
          await this.addColumn(table, newColumn)
          // update cloned table
          clonedTable = table.clone()
      } else {
+            if (typeOrLengthChanged) {
+                // Use ALTER COLUMN to preserve data instead of DROP + ADD
+                // SQL Server supports: ALTER TABLE t ALTER COLUMN col_name new_type [NULL | NOT NULL]
+                // Drop default constraint first if one exists (SQL Server requires this before ALTER COLUMN)
+                if (
+                    oldColumn.default !== null &&
+                    oldColumn.default !== undefined
+                ) {
+                    const defaultName =
+                        this.dataSource.namingStrategy.defaultConstraintName(
+                            table,
+                            oldColumn.name,
+                        )
+                    upQueries.push(
+                        new Query(
+                            `ALTER TABLE ${this.escapePath(
+                                table,
+                            )} DROP CONSTRAINT "${defaultName}"`,
+                        ),
+                    )
+                    downQueries.push(
+                        new Query(
+                            `ALTER TABLE ${this.escapePath(
+                                table,
+                            )} ADD CONSTRAINT "${defaultName}" DEFAULT ${oldColumn.default} FOR "${oldColumn.name}"`,
+                        ),
+                    )
+                }
+
+                upQueries.push(
+                    new Query(
+                        `ALTER TABLE ${this.escapePath(
+                            table,
+                        )} ALTER COLUMN ${this.buildCreateColumnSql(
+                            table,
+                            newColumn,
+                            true,
+                            false,
+                        )}`,
+                    ),
+                )
+                downQueries.push(
+                    new Query(
+                        `ALTER TABLE ${this.escapePath(
+                            table,
+                        )} ALTER COLUMN ${this.buildCreateColumnSql(
+                            table,
+                            oldColumn,
+                            true,
+                            false,
+                        )}`,
+                    ),
+                )

Evidence

BaseQueryRunner.isColumnChanged explicitly excludes type/length but includes
precision/scale/collation/isNullable. Therefore, a type change that also changes precision/scale (or
other tracked properties) will satisfy both typeOrLengthChanged and isColumnChanged, resulting
in two ALTER COLUMN queries. This is newly introduced by adding an ALTER COLUMN for type/length
changes without guarding the later ALTER COLUMN branch.

src/query-runner/BaseQueryRunner.ts[548-604]
src/driver/sqlserver/SqlServerQueryRunner.ts[1367-1420]
src/driver/sqlserver/SqlServerQueryRunner.ts[1771-1800]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`changeColumn` can generate two `ALTER COLUMN` statements for a single change when `typeOrLengthChanged` is true and `isColumnChanged` is also true due to other property differences (precision/scale/collation/nullability).
### Issue Context
- The new block adds `ALTER COLUMN` for type/length changes.
- The existing block later adds another `ALTER COLUMN` when `isColumnChanged(...)` is true.
### Fix Focus Areas
- src/driver/sqlserver/SqlServerQueryRunner.ts[1354-1450]
- src/driver/sqlserver/SqlServerQueryRunner.ts[1771-1800]
- src/query-runner/BaseQueryRunner.ts[548-604]
### What to change
- Introduce a guard so the later `isColumnChanged` ALTER COLUMN does not run when the earlier type/length ALTER COLUMN already applied the full column definition (including precision/scale/collation/nullability).
- Example: wrap the later block with `if (!typeOrLengthChanged && this.isColumnChanged(...))`.
- Alternatively, unify into a single ALTER COLUMN path that triggers when either `typeOrLengthChanged` or `isColumnChanged` is true.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

🐞 Bugs (0) 📘 Rule violations (2) 📎 Requirement gaps (0) 📐 Spec deviations (0)