When I remove entities in the dbContext, they are still in navigation properties of the entities

[ComptonAlvaro]

I have two entities like that:

Entity01
{
    ICollection<Entity02> myEntity02;
}
Entity02
{
    Entity01 myEntity01;
}

In EF 6, if do this:

Entity02 myEntity02;
myDbContext.Entity02.Remove(myEntity02);

When I delete the entity02 from the dbContext, the entity02 is also removed form the navigation property myEntity01.Entity02.

However, if I do the same in EF Core, the entity02 is deleted from myDbContext.Entity02 collection, but it still is in the property myEntity01.Entity02 property, so I have to delete it manually.

In my case, sometimes, I need to decide to delete myEntity01 if the property Entity01.Entity02 is empty, so in EF6 is easy because when I delete the entities in the dbContext, are delete in the entity property too, so checking if count is 0 it is enough. But in EF Core, how it still is in the navigation property of Entity01, I have to count excluding the entities that I have deleted in dbContext, so I guess that is less efficient because I have to iterate the collection . Something like that:

List<Entity02> myLstEntity02ToDelete = new List<Entity02>();
myLstEntity02.Add(myEntit02ToDelete);
myDbContext.Entity02.RemoveRange(myLstEntity02ToDelete);
if(myEntity01.Property02.All(x => myLstEntity02ToDelete.Contains(x) == true))
{
    //Delete entity01
}

So my question is, there are some way to configure EF Core to woks like EF 6 in this way? I would like that when I delete a property in dbContext, delete this entity from all the navigation properties of the entities that has this entity that I have delete from the dbContext.

Thanks.

[ajcvickers]

@ComptonAlvaro This difference in behavior from EF6 is intentional. With EF Core, the deleted entity is still removed from the collection, but it happens at SaveChanges time when the entity is actually deleted. The call to Remove just marks the entity for deletion--it doesn't actually remove it. The behavior that EF6 has makes certain things very hard because it results in "shredding" the graph--i.e. removing all navigations between entities--when just trying to change the state of entities.

[ajcvickers]

@divega Following discussion in triage I tested what actually happens. 😺 It is as described above--no navs get changed before SaveChanges. After SaveChanges we are a bit inconsistent. What is supposed to happen is that anything still tracked (i.e. the entity not deleted) will have its navs fixed up. For a Blog/Post model, this works if Post is deleted--it still points to the Blog afterwards, but the Blog no longer references the deleted Post. However, if Blog is deleted, then it's collection of Posts gets cleared out.

I'll file an issue for this--but wanted to check first that this behavior makes sense. The rationale is that if you delete a bunch of entities, then those that have been deleted still point to each other instead of it being completely shredded, If this was, for example, an aggregate, then it would make it easy to re-track it if necessary because with the deleted unit (i.e. the aggregate in this case) all relationships are maintained.

[divega]

@ajcvickers if I understand correctly, what you are proposing makes sense. What do you think the priority is? Should we try to do it for 2.0?

[ajcvickers]

@divega I think it's small enough to fit in 2.0--let's chat on Monday.

[ComptonAlvaro]

So if I understand correctly, the actual behavior will be changed? I mean that now if a blog is deleted and its collection is cleared, the post still point to the blog. This behavior will be changed? Anyway, I think that this is not coherent because one navigation is changed (the collection of the post) but the post still points to the blog.

I guess that it would be better clear all or not clear anything to avoid doubts or errors. And To keep the relations, not clearing the navigation properties, it is a good option too.

There are documentation about the actual behavior? Anyway, if the behavior is changed, it will make to some people to check the code of their application. Perhaps, one or other final behavior, it would be better to use local variables to track the entities that will be delete if the logic of the application depends on that, like the case that I exposed in my first post. Using local variables it will be more less affected in this kind of changes.

Thank so much.

[ComptonAlvaro]

Could you explain what will be the final behavior?

Thanks.

[ajcvickers]

@ComptonAlvaro After SaveChanges, any entity that is still tracked will have its navigation properties updated appropriately--no entities that are still tracked will point to any entity that has now been deleted. Any entity that is no longer tracked (i.e. in this case the entity that has now been deleted) will not have its navigation properties changed.

[cjblomqvist]

See also related issue #10114

[DeveloperSuccess]

@ComptonAlvaro After SaveChanges, any entity that is still tracked will have its navigation properties updated appropriately--no entities that are still tracked will point to any entity that has now been deleted. Any entity that is no longer tracked (i.e. in this case the entity that has now been deleted) will not have its navigation properties changed.

The ChangeTracker.DetectChanges() can't delete related links?

[cjblomqvist]

@ComptonAlvaro After SaveChanges, any entity that is still tracked will have its navigation properties updated appropriately--no entities that are still tracked will point to any entity that has now been deleted. Any entity that is no longer tracked (i.e. in this case the entity that has now been deleted) will not have its navigation properties changed.

The ChangeTracker.DetectChanges() can't delete related links?

It doesn't. That's intentional (as far as I've understood). It theoretically could, but that's another story.