Skip ALTER COLUMN for computed columns when only CLR type changes

[m-x-shokhzod]

The migration model differ produced an AlterColumnOperation when the CLR type of a property mapped to a computed column changed (e.g. int → long for a column with .HasComputedColumnSql("DATALENGTH(...)")). The resulting ALTER TABLE ... ALTER COLUMN then failed at runtime with:

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

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.

Fix

In MigrationsModelDiffer.Diff(IColumn, IColumn, DiffContext), suppress columnTypeChanged and collationChanged when both source and target are computed with the same ComputedColumnSql and IsStored:

var isComputedWithUnchangedExpression =
    source.ComputedColumnSql != null
    && target.ComputedColumnSql != null
    && MultilineEquals(source.ComputedColumnSql, target.ComputedColumnSql)
    && source.IsStored == target.IsStored;

var columnTypeChanged = !isComputedWithUnchangedExpression && source.StoreType != target.StoreType;
var collationChanged = !isComputedWithUnchangedExpression && source.Collation != target.Collation;

Behavior

Scenario	Before	After
Computed column, CLR type changes (int → long), same expression	AlterColumnOperation → ALTER COLUMN → SQL Server rejects	No-op migration ✓
Computed column, expression changes (DATALENGTH → LEN)	AlterColumnOperation → SQL generator's drop+add path	Unchanged — still triggers drop+add ✓
Non-computed column, type changes	AlterColumnOperation → ALTER COLUMN	Unchanged ✓
Computed column, nullability/comment/order/annotation changes	AlterColumnOperation produced	Unchanged — still produced ✓

Tests

• Computed_column_clr_type_change_alone_is_no_op — bug case from Migration tries to alter column type of computed column if CLR type changes. #33425; reproduces exactly with DATALENGTH([FileContents]) and asserts zero operations
• Computed_column_expression_change_with_clr_type_change_still_alters — guards the existing drop+add path

Full Relational.Tests suite passes (1427/1428, the 1 skip is pre-existing). SqlServer.Tests suite passes (1335/1335). End-to-end coverage will run on the SqlServer 2019/2022/2025 CI matrix.

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.