-
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 inner entity with owned properties in the in-memory database #23934
Comments
Note for triage: regression from 3.1. Logs:
|
Removing this from backlog for consider not patching this.
Even if we manage to come with set of conditions to play with indexes to fix this particular issue, we may cause another regression in some other case. Given there is work-around possible here and risk is high, we should avoid patching this and rather fix #21677 for 6.0 to fix these issues more robustly. |
@smitpatel, thank you for your investigation of the problem. |
Client side work-around is to call following line right before the query AppContext.SetSwitch("Microsoft.EntityFrameworkCore.Issue23285", true); If the app is working for you with calling above code only once at the startup then that is also fine. If there are other queries which would break with it then you can set the switch to false again after your above query has executed. |
If I set AppContext.SetSwitch("Microsoft.EntityFrameworkCore.Issue23285", true); then instead of
I get
in my unit tests |
@AntonPervushin Given that setting the AppContext switch works with the repro code posted above, this means that there must be something different about the issue in your production code. Could you update the code you posted so that it fails in the same way as your production code when setting the AppContext switch? Also, could you post the full stack trace of the failure you are getting with the AppContext switch set? |
@ajcvickers I can not reproduce that with test model yet. |
Implement left join as client method to reduce complexity To resolve the indexing issue stemming from #23934 Now all the projections are applied immediately to reshape the value buffer so that all our future bindings are always read value expressions which refers to a proper index. In order to do this, we apply select for entity type with hierarchy to avoid entity check conditional expression. For adding projection (through ReplaceProjectionMapping), - For client projection, we apply a select and re-generate client projection as read values - For projection mapping, we iterate the mappings, we apply a select and re-generate the mapping as read values - If projection mapping is empty then we add a dummy 1 so that it becomes non-range-variable When applying projection, we generate a selector lambda to form a value buffer and replaced all the expressions to read from new value buffer. Overall this solves the issue of having complex expressions to map or pull. This also removed PushDownIntoSubquery method. In order to avoid the issue of indexes changing when generating join due to iterating projection mappings, we now also have projectionMappingExpressions which remembers the all expressions inside projectionMapping (which are all read value as we generated before). So now we don't need to iterate the mapping and we use the existing expressions directly. This keeps existing indexes. Resolves #13561 Resolves #17539 Resolves #18194 Resolves #18435 Resolves #19344 Resolves #19469 Resolves #19667 Resolves #19742 Resolves #19967 Resolves #20359 Resolves #21677 Resolves #23360 Resolves #17537 Resolves #18394 Resolves #23934
Implement left join as client method to reduce complexity To resolve the indexing issue stemming from #23934 Now all the projections are applied immediately to reshape the value buffer so that all our future bindings are always read value expressions which refers to a proper index. In order to do this, we apply select for entity type with hierarchy to avoid entity check conditional expression. For adding projection (through ReplaceProjectionMapping), - For client projection, we apply a select and re-generate client projection as read values - For projection mapping, we iterate the mappings, we apply a select and re-generate the mapping as read values - If projection mapping is empty then we add a dummy 1 so that it becomes non-range-variable When applying projection, we generate a selector lambda to form a value buffer and replace all the expressions to read from new value buffer. Overall this solves the issue of having complex expressions to map or pull. This also removed PushDownIntoSubquery method. In order to avoid the issue of indexes changing when generating join due to iterating projection mappings, we now also have projectionMappingExpressions which remembers the all expressions inside projectionMapping (which are all read value as we generated before). So now we don't need to iterate the mapping and we use the existing expressions directly. This keeps existing indexes. Resolves #13561 Resolves #17539 Resolves #18194 Resolves #18435 Resolves #19344 Resolves #19469 Resolves #19667 Resolves #19742 Resolves #19967 Resolves #20359 Resolves #21677 Resolves #23360 Resolves #17537 Resolves #18394 Resolves #23934
Implement left join as client method to reduce complexity To resolve the indexing issue stemming from #23934 Now all the projections are applied immediately to reshape the value buffer so that all our future bindings are always read value expressions which refers to a proper index. In order to do this, we apply select for entity type with hierarchy to avoid entity check conditional expression. For adding projection (through ReplaceProjectionMapping), - For client projection, we apply a select and re-generate client projection as read values - For projection mapping, we iterate the mappings, we apply a select and re-generate the mapping as read values - If projection mapping is empty then we add a dummy 1 so that it becomes non-range-variable When applying projection, we generate a selector lambda to form a value buffer and replace all the expressions to read from new value buffer. Overall this solves the issue of having complex expressions to map or pull. This also removed PushDownIntoSubquery method. In order to avoid the issue of indexes changing when generating join due to iterating projection mappings, we now also have projectionMappingExpressions which remembers the all expressions inside projectionMapping (which are all read value as we generated before). So now we don't need to iterate the mapping and we use the existing expressions directly. This keeps existing indexes. Resolves #13561 Resolves #17539 Resolves #18194 Resolves #18435 Resolves #19344 Resolves #19469 Resolves #19667 Resolves #19742 Resolves #19967 Resolves #20359 Resolves #21677 Resolves #23360 Resolves #17537 Resolves #18394 Resolves #23934 Resolves #17620 Resolves #18912
Implement left join as client method to reduce complexity To resolve the indexing issue stemming from #23934 Now all the projections are applied immediately to reshape the value buffer so that all our future bindings are always read value expressions which refers to a proper index. In order to do this, we apply select for entity type with hierarchy to avoid entity check conditional expression. For adding projection (through ReplaceProjectionMapping), - For client projection, we apply a select and re-generate client projection as read values - For projection mapping, we iterate the mappings, we apply a select and re-generate the mapping as read values - If projection mapping is empty then we add a dummy 1 so that it becomes non-range-variable When applying projection, we generate a selector lambda to form a value buffer and replace all the expressions to read from new value buffer. Overall this solves the issue of having complex expressions to map or pull. This also removed PushDownIntoSubquery method. In order to avoid the issue of indexes changing when generating join due to iterating projection mappings, we now also have projectionMappingExpressions which remembers the all expressions inside projectionMapping (which are all read value as we generated before). So now we don't need to iterate the mapping and we use the existing expressions directly. This keeps existing indexes. Resolves #13561 Resolves #17539 Resolves #18194 Resolves #18435 Resolves #19344 Resolves #19469 Resolves #19667 Resolves #19742 Resolves #19967 Resolves #20359 Resolves #21677 Resolves #23360 Resolves #17537 Resolves #18394 Resolves #23934
Implement left join as client method to reduce complexity To resolve the indexing issue stemming from #23934 Now all the projections are applied immediately to reshape the value buffer so that all our future bindings are always read value expressions which refers to a proper index. In order to do this, we apply select for entity type with hierarchy to avoid entity check conditional expression. For adding projection (through ReplaceProjectionMapping), - For client projection, we apply a select and re-generate client projection as read values - For projection mapping, we iterate the mappings, we apply a select and re-generate the mapping as read values - If projection mapping is empty then we add a dummy 1 so that it becomes non-range-variable When applying projection, we generate a selector lambda to form a value buffer and replace all the expressions to read from new value buffer. Overall this solves the issue of having complex expressions to map or pull. This also removed PushDownIntoSubquery method. In order to avoid the issue of indexes changing when generating join due to iterating projection mappings, we now also have projectionMappingExpressions which remembers the all expressions inside projectionMapping (which are all read value as we generated before). So now we don't need to iterate the mapping and we use the existing expressions directly. This keeps existing indexes. Resolves #13561 Resolves #17539 Resolves #18194 Resolves #18435 Resolves #19344 Resolves #19469 Resolves #19667 Resolves #19742 Resolves #19967 Resolves #20359 Resolves #21677 Resolves #23360 Resolves #17537 Resolves #18394 Resolves #23934 # Conflicts: # test/EFCore.InMemory.FunctionalTests/Query/NorthwindGroupByQueryInMemoryTest.cs
Implement left join as client method to reduce complexity To resolve the indexing issue stemming from #23934 Now all the projections are applied immediately to reshape the value buffer so that all our future bindings are always read value expressions which refers to a proper index. In order to do this, we apply select for entity type with hierarchy to avoid entity check conditional expression. For adding projection (through ReplaceProjectionMapping), - For client projection, we apply a select and re-generate client projection as read values - For projection mapping, we iterate the mappings, we apply a select and re-generate the mapping as read values - If projection mapping is empty then we add a dummy 1 so that it becomes non-range-variable When applying projection, we generate a selector lambda to form a value buffer and replace all the expressions to read from new value buffer. Overall this solves the issue of having complex expressions to map or pull. This also removed PushDownIntoSubquery method. In order to avoid the issue of indexes changing when generating join due to iterating projection mappings, we now also have projectionMappingExpressions which remembers the all expressions inside projectionMapping (which are all read value as we generated before). So now we don't need to iterate the mapping and we use the existing expressions directly. This keeps existing indexes. Resolves #13561 Resolves #17539 Resolves #18194 Resolves #18435 Resolves #19344 Resolves #19469 Resolves #19667 Resolves #19742 Resolves #19967 Resolves #20359 Resolves #21677 Resolves #23360 Resolves #17537 Resolves #18394 Resolves #23934 # Conflicts: # test/EFCore.InMemory.FunctionalTests/Query/NorthwindGroupByQueryInMemoryTest.cs
Getting an exception when using a queries with an owned property in an internal property.
Looks like related to #23285
But that bug is realy fixed.
I took test model from that issue and get an exception in 5.0.0. And have no exception in 5.0.2 with that test model.
But I have an exception with my test model.
Test model
Test case
Stack trace:
at System.Linq.Enumerable.WhereSelectEnumerableIterator
2.MoveNext() at Microsoft.EntityFrameworkCore.InMemory.Query.Internal.InMemoryShapedQueryCompilingExpressionVisitor.QueryingEnumerable
1.Enumerator.MoveNextHelper()at Microsoft.EntityFrameworkCore.InMemory.Query.Internal.InMemoryShapedQueryCompilingExpressionVisitor.QueryingEnumerable
1.Enumerator.MoveNext() at System.Collections.Generic.List
1..ctor(IEnumerable1 collection) at System.Linq.Enumerable.ToList[TSource](IEnumerable
1 source)at
...MyTest.cs:line 43
EF Core version: 5.0.1
Microsoft.EntityFrameworkCore.InMemory version 5.0.2
Database provider: Microsoft.EntityFrameworkCore.SqlServer/Microsoft.EntityFrameworkCore.InMemory
Target framework: (NET 3.1)
Operating system:
IDE: (Microsoft Visual Studio Professional 2019 16.7.6)
The text was updated successfully, but these errors were encountered: