Skip ALTER COLUMN for computed columns when only CLR type changes

[m-x-shokhzod]

Migrations for properties mapped to a computed column failed at runtime when only the CLR type changed (e.g. int → long for a column with .HasComputedColumnSql("DATALENGTH(...)")). EF emitted ALTER TABLE ... ALTER COLUMN, which SQL Server rejected with:

Cannot alter column 'FileSize' because it is 'COMPUTED'.

A computed column's store type is derived from the expression, so a CLR-type-only change is metadata on the EF side and requires no database-side change.

Fix

In SqlServerMigrationsSqlGenerator.Generate(AlterColumnOperation), detect the no-op case once and use it to short-circuit both the index drop/recreate path and the ALTER COLUMN emission:

var narrowed = false;
var oldColumnSupported = IsOldColumnSupported(model);

// SQL Server can't ALTER COLUMN on a computed column when the expression is unchanged; see #33425.
var computedColumnIsNoOp = operation.ComputedColumnSql != null
    && operation.OldColumn.ComputedColumnSql != null
    && operation.ComputedColumnSql == operation.OldColumn.ComputedColumnSql
    && operation.IsStored == operation.OldColumn.IsStored;

if (oldColumnSupported && !computedColumnIsNoOp)
{
    // ... narrowed = ... (skipped when computed is unchanged)
}

// later
if (computedColumnIsNoOp)
{
    alterStatementNeeded = false;
}

The flag is computed once and gates two sites:

1. The narrowed block at the top — prevents GetIndexesToRebuild / DropIndexes / CreateIndexes from running for a column the DB won't see modified.
2. The alterStatementNeeded reset — suppresses the actual ALTER COLUMN SQL.

The provider-independent MigrationsModelDiffer is untouched — the constraint is SQL Server-specific (PostgreSQL/SQLite generated-column rules differ, MySQL allows MODIFY COLUMN on generated columns), so the suppression belongs in the SQL Server generator.

Comment changes via sp_addextendedproperty further down still run — this is intentional and covered by the existing Alter_computed_column_add_comment regression test.

Behavior

Scenario	Before	After
Computed column, CLR type changes, same expression	ALTER COLUMN → SQL Server rejects	No SQL emitted, no index rebuild
Computed column, expression changes	Drop+add path	Unchanged
Non-computed column, type changes	ALTER COLUMN	Unchanged
Computed column, comment changes	sp_addextendedproperty	Unchanged

Tests

Generator-level (SqlServerMigrationsSqlGeneratorTest):

• AlterColumnOperation_computed_column_with_only_clr_type_change_is_noop — asserts empty SQL for the bug case
• AlterColumnOperation_computed_column_with_changed_expression_drops_and_adds — guards the existing drop+add path

End-to-end (MigrationsSqlServerTest):

• Alter_computed_column_clr_type_only_change_is_noop — full migration against real SQL Server, zero SQL
• Alter_computed_column_clr_type_only_change_does_not_rebuild_indexes — same scenario with an index on the computed column, asserts no DROP INDEX / CREATE INDEX (would have caught the original Copilot-flagged regression)

CI matrix (SqlServer 2019/2022/2025) covers end-to-end execution.

Fixes #33425

[roji]

A computed column's store type and collation are derived from the expression; they aren't user-configurable. CLR-type-only changes are metadata on the EF side and require no database-side change.

Have you verified whether this is a SQL Server-specific thing, or universal to all databases? I'm pretty sure it's the former, in which case you're introducing a SQL Server-specific change into ModelDiffer, which is provider-independent.

[m-x-shokhzod]

Good point — you're right. The constraint is SQL Server specific: PostgreSQL and SQLite have similar but narrower restrictions on generated columns, and MySQL handles type changes on generated columns fine via MODIFY COLUMN.

Reworked (force-pushed cdc292aff8):

• MigrationsModelDiffer.cs reverted to upstream main — provider-independent again.
• The fix now lives in SqlServerMigrationsSqlGenerator.Generate(AlterColumnOperation): when both source and target are computed, alterStatementNeeded is set to false. This suppresses only the ALTER COLUMN emission; the comment block via sp_addextendedproperty further down still runs (which the unit test approach in my first version missed — caught by the Alter_computed_column_add_comment regression).
• Added an end-to-end test Alter_computed_column_clr_type_only_change_is_noop in MigrationsSqlServerTest that exercises the customer-reported scenario end-to-end. Verified locally against real SQL Server (Azure SQL Edge on Apple Silicon) — passes. Will also run on the SqlServer 2019/2022/2025 CI matrix.

[Copilot]

Pull request overview

This PR addresses SQL Server migrations failing when EF scaffolds an ALTER COLUMN for a computed column whose CLR type changed (e.g. int → long) while the computed expression is unchanged. Since SQL Server rejects ALTER COLUMN on computed columns, the generator is updated to avoid emitting that SQL and new regression tests are added.

Changes:

• Suppress ALTER TABLE ... ALTER COLUMN SQL generation for computed columns when both old/new are computed (leaving expression-change behavior intact via the existing drop+add path).
• Add SQL generator regression coverage for “CLR type only” changes (no SQL) vs expression changes (drop+add).
• Add end-to-end migrations functional coverage ensuring the migration completes without emitting SQL for the CLR-type-only scenario.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/EFCore.SqlServer/Migrations/SqlServerMigrationsSqlGenerator.cs	Avoids emitting ALTER COLUMN for computed columns (when both old/new are computed).
test/EFCore.SqlServer.FunctionalTests/Migrations/SqlServerMigrationsSqlGeneratorTest.cs	Adds generator-level regression tests for computed columns (no-op vs drop+add).
test/EFCore.SqlServer.FunctionalTests/Migrations/MigrationsSqlServerTest.cs	Adds functional regression test ensuring no SQL is emitted for CLR-type-only computed column changes.