-
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
Does not save a navigation property of an item inside collection #3997
Comments
Hey, This is currently by design. When you add an entity to the context, by default, it recursively adds children/dependents to the context too. Since ClassB is a child/dependent in the ClassA -> ClassB relationship, the ClassB instance gets added too. ClassC is the parent/principal in the ClassB -> ClassC relationship, so those instances do not get added. There are overloads of Add which allow you to specify a "graph behavior" to control what gets added. To have the ClassC instance be added, you need to call Add on it as well. BTW several folks have found this behavior confusing, so we are discussing changing it at the moment. ~Rowan |
Hi, I think such definition of parent/child (principal/dependent) is not quite accurate. Because both classes ClassB or ClassC could be either Parent or Child depending on your application design. For instance: class Parent
{
public Child Child;
}
// or it can be
public class Child
{
public Parent Parent;
} It looks like a design defect to me especially if you are going to add "Value Objects" support (#246) |
The relationship between ClassB and ClassC looks more like a relationship rather than a value object because ClassC has a primary key. Value/complex objects are just groupings of properties that are conceptually part of the entity they are referenced from. Based on that, it would need to be a relationship and a relationship always has a principal and dependent (one end with the primary key and the other with the foreign key). If you did want to model it as a complex/value object (when #246 is implemented) then the graph behavior I described would be irrelevant because the properties in ClassC would conceptually just be nested properties in ClassB. |
I understand your point, from the database point of view you could say that ClassC is principal because it has a primary key and ClassB has a foreign key reference to ClassC. But in my hypothetical application I consider the ClassB as a primary class and ClassC is an "attribute". Anyhow, imho this feature could be useful but if you decide to not implement it its not the end of the world. Thank you! |
I have the following hierarchy
When I try to save the following structure to the database it does not save the CItem property
The text was updated successfully, but these errors were encountered: