Fix computed column nullability mismatch in temporal table migrations

[Copilot]

When adding computed columns to temporal tables in EF9, migrations could fail with "Setting SYSTEM_VERSIONING to ON failed because column does not have the same nullability attribute in tables" due to inconsistent nullability between the main table and history table columns.

The issue occurred because computed columns in the main table (e.g., AS 5 PERSISTED) have their nullability determined by SQL Server based on the computation, while the corresponding column in the history table was created as a regular column without ensuring matching nullability.

Consider this migration that would fail in EF9:

migrationBuilder.AddColumn<int>(
    name: "Five",
    table: "Customer", 
    computedColumnSql: "5 PERSISTED");

This generates:

• Main table: ADD [Five] AS 5 PERSISTED (implicitly non-nullable)
• History table: ADD [Five] int NULL (potentially nullable, causing mismatch)

Fix:

• Ensures computed columns in history tables have consistent nullability with their main table counterparts
• Automatically sets IsNullable = false for computed column history table equivalents
• Provides appropriate default values to maintain data integrity

This resolves the temporal table versioning failure while maintaining backward compatibility for existing temporal table functionality.

Fixes #35180.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[AndriySvyryd]

Don't add tests for this case. If the user adds a manual operation that changes SYSTEM_VERSIONING then we can no longer guarantee the behavior, so remove the code that looks for this.

Instead change the Add_non_nullable_computed_column_to_temporal_table() test case to use a non constant value:
e.Property<int>("Five").HasComputedColumnSql("5 PERSISTED"); and fix the resulting issue " Microsoft.Data.SqlClient.SqlException : Setting SYSTEM_VERSIONING to ON failed because column 'Five' does not have the same nullability attribute in tables 'MigrationsSqlServerTest.dbo.Customer' and 'MigrationsSqlServerTest.dbo.HistoryTable'."

[AndriySvyryd]

@copilot
Don't add tests for this case. If the user adds a manual operation that changes SYSTEM_VERSIONING then we can no longer guarantee the behavior, so remove the code that looks for this.

Instead change the Add_non_nullable_computed_column_to_temporal_table() test case to use a non constant value:
e.Property("Five").HasComputedColumnSql("Id + 5"); and fix the resulting issue " Microsoft.Data.SqlClient.SqlException : Setting SYSTEM_VERSIONING to ON failed because column 'Five' does not have the same nullability attribute in tables 'MigrationsSqlServerTest.dbo.Customer' and 'MigrationsSqlServerTest.dbo.HistoryTable'."

[AndriySvyryd]

@copilot Try the above comment again

[Copilot]

I've removed the manual SYSTEM_VERSIONING detection code and tests as requested. Instead, I've fixed the core issue with computed columns in temporal tables by ensuring proper nullability matching between the main table and history table columns. The fix addresses the "Setting SYSTEM_VERSIONING to ON failed because column does not have the same nullability attribute" error by making computed column history table columns consistently non-nullable with appropriate default values. Changes are in commit 77b098b.

[Copilot]

@AndriySvyryd Unfortunately I hit an unexpected error while processing your comment. I've automatically reported this to GitHub.

You can ask me to try again later by mentioning me in a new comment.

If you want to contact GitHub about this error, please mention the following identifier so they can better serve you: 9fd0f09a-74f4-44fa-b07d-eb42e886f681

Sorry for the inconvenience!