Section: Teams
X4 / nobodies-collective#592 requires a nullable Teams.ExternalCalendarUrl column (max length 2048) in one EF-generated schema-only migration. Teams currently has six HasData system-team rows.
With EF Core 10.0.10, the ordinary nullable mapping generates the column addition plus six UpdateData operations setting only the new column to null. An explicit SQL NULL default instead produces six empty UpdateData operations, which cannot ship. Explicit null seed values cannot solve this: EF marks a seeded row modified whenever a target column has no matching source column. Computed/generated-on-update mappings would misrepresent this editable property.
Evidence: https://github.com/dotnet/efcore/blob/v10.0.10/src/EFCore.Relational/Migrations/Internal/MigrationsModelDiffer.cs#L2174-L2185
The repository requires zero data SQL in migrations and forbids editing generated migration/snapshot files. No schema-only migration has been found for the intended honest mapping under these constraints. Independent architecture review confirmed the conflict. The experimental default and invalid migration remain uncommitted; no migration has been applied.
Resolve the tooling/model-policy conflict before shipping the external calendar column. Do not hand-edit the migration, suppress seed writes through a false mapping, or add a runtime backfill. The independently requested role-name index drop and image functionality do not require a data repair.
Section: Teams
X4 / nobodies-collective#592 requires a nullable Teams.ExternalCalendarUrl column (max length 2048) in one EF-generated schema-only migration. Teams currently has six HasData system-team rows.
With EF Core 10.0.10, the ordinary nullable mapping generates the column addition plus six UpdateData operations setting only the new column to null. An explicit SQL NULL default instead produces six empty UpdateData operations, which cannot ship. Explicit null seed values cannot solve this: EF marks a seeded row modified whenever a target column has no matching source column. Computed/generated-on-update mappings would misrepresent this editable property.
Evidence: https://github.com/dotnet/efcore/blob/v10.0.10/src/EFCore.Relational/Migrations/Internal/MigrationsModelDiffer.cs#L2174-L2185
The repository requires zero data SQL in migrations and forbids editing generated migration/snapshot files. No schema-only migration has been found for the intended honest mapping under these constraints. Independent architecture review confirmed the conflict. The experimental default and invalid migration remain uncommitted; no migration has been applied.
Resolve the tooling/model-policy conflict before shipping the external calendar column. Do not hand-edit the migration, suppress seed writes through a false mapping, or add a runtime backfill. The independently requested role-name index drop and image functionality do not require a data repair.