search

dotnet / EntityFramework.Docs

Documentation for Entity Framework Core and Entity Framework 6
https://docs.microsoft.com/ef/
Creative Commons Attribution 4.0 International
1.62k stars 1.96k forks source link

Document that required columns are created nullable when table splitting #3750

Open ajcvickers opened 2 years ago

ajcvickers commented 2 years ago

See https://github.com/dotnet/efcore/issues/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 commented 2 years ago

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 commented 2 years ago

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. https://github.com/dotnet/efcore/issues/25359 is to make the overall behavior better.

syska commented 2 years ago

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.