-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exception when using inheritance with owned properties in the in-memory database #23285
Comments
@smitpatel @maumar This is a regression in 5.0. Stack trace:
|
Note: error only happens in InMemory. Works for SqlServer correctly. |
Meanwhile, initializing reference navigations in the ctor causes errors. See https://docs.microsoft.com/en-us/ef/core/what-is-new/ef-core-5.0/breaking-changes#nonnullreferences |
@smitpatel I missed |
No that is not the root cause. There is a bug in InMemory but once that is fixed, the reference navigation can have side-effects in the app as usual. |
Resolves #23285 Now my long paragraph to future contributors to this file This issue reverts the fix from #22202 and fixes it differently. The main issue is that when we generate a LeftJoin through GJ-DIE-SM pattern we need to generate result selector for SM scenario. In this result selector, either we copy VB from source as is and the preserve the inner projection mapping with remapped parameters or we apply projection through the result selector and regenerate bindings for outer. What happened in #22202 that when generating result selector and new bindings, we changed indexes of VB which broke owned navigation mappings. So we fixed that by preserving indexes from entity projections in WeakNavigation expansion scenario. This caused side-effect that now we are applying selector for non-entity projection but preserving VB slots for entity projections. Further we used the read expression to preserve value buffer as is meaning multiple different properties which are in same slot were not preserved correctly causing InvalidCastException while reading. A better approach is to generate result selector accounting for the owned navigations too. Essentially add owned navigation projections to result selector too. This has to happen in both case, when adding LeftJoin in non-owned scenario and in owned scenario. Overall it makes all indexes happy. Thus, harmony in the universe was restored.
Seems correct, I might've mixed that up with another minor issue: Inheritance hierarchies with the same property names have different column names implicitly generated compared to efcore3.1. So changing ef core from 3.1 to 5.0 causes columns and properties to mapped incorrectly in some cases. But there is an easy workaround of just assigning an explicit column name. |
Resolves #23285 Now my long paragraph to future contributors to this file This issue reverts the fix from #22202 and fixes it differently. The main issue is that when we generate a LeftJoin through GJ-DIE-SM pattern we need to generate result selector for SM scenario. In this result selector, either we copy VB from source as is and the preserve the inner projection mapping with remapped parameters or we apply projection through the result selector and regenerate bindings for outer. What happened in #22202 that when generating result selector and new bindings, we changed indexes of VB which broke owned navigation mappings. So we fixed that by preserving indexes from entity projections in WeakNavigation expansion scenario. This caused side-effect that now we are applying selector for non-entity projection but preserving VB slots for entity projections. Further we used the read expression to preserve value buffer as is meaning multiple different properties which are in same slot were not preserved correctly causing InvalidCastException while reading. A better approach is to generate result selector accounting for the owned navigations too. Essentially add owned navigation projections to result selector too. This has to happen in both case, when adding LeftJoin in non-owned scenario and in owned scenario. Overall it makes all indexes happy. Thus, harmony in the universe was restored.
Using owned properties within class inheritance hierarchies causes columns/properties to be mapped incorrctly, or causes various exception to be thrown when trying to read something from DbContext.
Setup
Testcase
What exactly happens depends on the class setup. In this example a
InvalidCastException
is thrown.If
ChildB.Prop
is a nullable property, aNullReferenceException
is thrown.If Prop of both child classes are nullable, then null is always returned regardless what has been saved.
Might be related to #23211 and/or #23276
EF Core version: 5.0.0
Database provider: Microsoft.EntityFrameworkCore.SqlServer/Microsoft.EntityFrameworkCore.InMemory
Target framework: NET 5.0
Operating system: Windows 10, 2004
IDE: Visual Studio 2019 16.8
The text was updated successfully, but these errors were encountered: