-
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
RC2: Regression with Parent/Child relationship #5674
Comments
Confirmed that this is a bug. When loading the Widgets the self-referencing relationship is not being fixed up. The workaround is to include the child collection in the query: var widgets = context.Widgets.Include(e => e.ChildWidgets).ToList(); This is a situation where the state manager is expecting query to do the fixup since it is all self-contained within the query, which means query needs to be able to do it anyway to support no-tracking queries. However, I suspect from the perspective of query it will never do this fixup, even for no-tracking queries, because the navigation property is not included in the query. In other words, if you do a no-tracking query for entities with self references, then those references will never be fixed up. If you want them to be fixed up, then you have do an Include. If we decide that this is the correct behavior for query, then the state manager cannot use fast single query mode for tracked queries that contain self references. |
Issue #5674 The state manager was assuming the query would take care of fixup for all single queries. However, this is only true when the relationships are explicitly included in the query. For some cases such as self references and multiple relationships between entity types, fixup is needed that will not be performed by query. Therefore we will now drop out of single query mode for any query with self refs and any time multiple entities are returned. This will have a perf impact, but super simple queries will still run in single query mode. Post RTM we will try to do something better.
Thanks for the suggestion of a workaround - I think that will be fine for our use case for now. While continuing to experiment I found another anomaly in the same area - if you explicitly query for the child widgets without using
Not sure what the expected behaviour should be here, but I don't think it should depend on which objects have already been loaded previously. |
@rwg0 The bug is due to fixup not happening in query. The change In have out for this will therefore fix the issues in the second repro as well. |
Issue #5674 The state manager was assuming the query would take care of fixup for all single queries. However, this is only true when the relationships are explicitly included in the query. For some cases such as self references and multiple relationships between entity types, fixup is needed that will not be performed by query. Therefore we will now drop out of single query mode for any query with self refs and any time multiple entities are returned. This will have a perf impact, but super simple queries will still run in single query mode. Post RTM we will try to do something better.
Issue #5674 The state manager was assuming the query would take care of fixup for all single queries. However, this is only true when the relationships are explicitly included in the query. For some cases such as self references and multiple relationships between entity types, fixup is needed that will not be performed by query. Therefore we will now drop out of single query mode for any query with self refs and any time multiple entities are returned. This will have a perf impact, but super simple queries will still run in single query mode. Post RTM we will try to do something better.
Sorry for really stupid question, but since we're having this as well - what version should we be targeting to get the fix? 1.0.0 was released 16 days ago and this fix was committed at the time of writing 8 days ago. We have a parent/child relation like the one on this issue and null reference flying from same method in the internals. |
@mkontula Fix is in 1.0.0. |
@ajcvickers Thanks for the info. I actually found out a way to make it brake, when you setup the parent/child relation for parent AND child and then SaveChanges to context. I'll make reproable sample later. |
Steps to reproduce
Use the following code to reproduce:
Add nuget packages for appropriate version of EntityFramework.Sqlite/EntityFrameworkCore.Sqlite and EntityFramework.Commands/EntityFrameworkCore.Tools.
Create an initial migration.
The issue
On RC2, the ChildWidgets collection on each Widget when loading the entire table, so the line
Console.WriteLine(widgets[1].ChildWidgets.Count);
throws a
NullReferenceException
. This works correctly on RC1.Additionally, changing the ParentWidget of a Widget that already has a parent set fails when the changes are saved to the database with the following exception.
Again, this works correctly on RC1. I suspect this may be a consequence of the
ChildWidget
list being left null - so a maybe just another symptom of the first problem.Further technical details
EF Core version: 1.0.0-rc2-final
Operating system: Windows 10 Pro x64
Visual Studio version: VS2015 update 2
Other details about my project setup: Console App, Target : .NET 4.5.2
The text was updated successfully, but these errors were encountered: