Does not save a navigation property of an item inside collection

[zilloy]

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]

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]

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]

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]

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!