Skip to content
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

Closed
zilloy opened this issue Dec 7, 2015 · 4 comments
Closed

Does not save a navigation property of an item inside collection #3997

zilloy opened this issue Dec 7, 2015 · 4 comments

Comments

@zilloy
Copy link

zilloy commented Dec 7, 2015

I have the following hierarchy

public class ClassA
    {
        public int Id { get; set; }
        public ICollection<ClassB> BItems { get; set; }
    }

public class ClassB
    {
        public int Id { get; set; }
        public int Name { get; set; }
        public ClassC CItem { get; set; }
    }

public class ClassC
    {
        public int Id { get; set; }
        public int Name { get; set; }
    }

When I try to save the following structure to the database it does not save the CItem property

var a = new ClassA 
{
    BItems = new Collection<ClassB>
            {
                new ClassB
                {
                    Name = "B",
                    CItem = new ClassC
                    {
                        Name = "C"
                    }
                }
            }
};
@rowanmiller
Copy link
Contributor

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

@zilloy
Copy link
Author

zilloy commented Dec 17, 2015

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)

@rowanmiller
Copy link
Contributor

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.

@zilloy
Copy link
Author

zilloy commented Dec 18, 2015

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".
The fact that ClassC has an ID does not make it principal, I just want to "reuse" ClassC objects across different ClassB's and avoid data duplication (we are talking about relational databases here though :)).

Anyhow, imho this feature could be useful but if you decide to not implement it its not the end of the world.

Thank you!

@ajcvickers ajcvickers reopened this Oct 16, 2022
@ajcvickers ajcvickers closed this as not planned Won't fix, can't repro, duplicate, stale Oct 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants