Document that required columns are created nullable when table splitting

[ajcvickers]

See dotnet/efcore#27516

The issue here is that our guidance is to introduce a required property in optional dependents. However, when table splitting, which is the default for owned types, Migrations will create a nullable column with a null default for this property. This makes all existing dependents effectively disappear. We need to document that the existing rows need to be populated with a non-null value so that they are detected as existing.

[IndigoHealth]

Oh! So just to expand on @ajcvickers comment... This issue (having a NULL value in the database in a column mapped to a non-nullable C# data type) only affects existing data. Data committed to the database after the new column has been added will get a non-null value for the new column assuming it is mapped to a non-nullable C# data type.

We need to document that the existing rows need to be populated with a non-null value

Is this "how it's supposed to work"? You're saying that we need to just know (or be told) to run a query or write some special-purpose code every time we add a non-nullable property to an owned entity in the data model? That's a disaster just waiting to happen. (Although the bright-yellow highlighted warning when we run the migration certainly gets our attention. If the warning gave us better guidance then, yeah, it's a breaking change with a manual fix. A little less than optimal but workable...)

[ajcvickers]

Is this "how it's supposed to work"? You're saying that we need to just know (or be told) to run a query or write some special-purpose code every time we add a non-nullable property to an owned entity in the data model?

Typically it just requires editing the migration. This issue is to make sure to document this better. dotnet/efcore#25359 is to make the overall behavior better.

[syska]

That's a disaster just waiting to happen.

Well ... I guess it run in local dev and will make sure you know it's broken.

Could that be a better experience ... probably. But by far not a disaster unless I'm missing something.