Allow delete orphans behavior to be configured differently than cascade delete behavior

[ajbeaven]

I have the following relationship set up between parent and child entities:

entity.HasOne(d => d.ParentEntity)
    .WithMany(p => p.ChildEntity)
    .HasForeignKey(d => d.IdParentEntity)
    .OnDelete(DeleteBehavior.Restrict)
    .HasConstraintName("FK_Name");

The DeleteBehavior specified here is for the express purpose of avoiding cyclic cascades. In practice, when I sever the relationship between these two entities, I want to delete the EntityChild.

I was a bit surprised to receive the following error when I ran the code parentEntity.Children.Remove(child):

The association between entity types 'ParentEntity' and 'ChildEntity' has been severed but the foreign key for this relationship cannot be set to null. If the dependent entity should be deleted, then setup the relationship to use cascade deletes.

My understanding of the OnDelete action is that it specifies the action to take when ParentEntity is deleted. ParentEntity is not being deleted in the case above, so I question why the OnDelete action has any bearing as to what occurs here.

I'd like to be able to avoid cyclic cascades and still be able to delete ChildEntities via EntityCollection.Remove(TEntity). One alternative is to use ObjectContext.DeleteObject(TEntity) however the ChildEntity removal is occurring in a ParentEntity method (I'm encapsulating the child collection) where there should be no reference to the ObjectContext.

I think it makes sense that if the foreign key for the relationship cannot be set to null that deletion occurs irrespective of the relationship's OnDelete behavior. Perhaps the current behavior is typical of how ORMs handle this sort of thing, but I figured I'd log this just in case.

[ajcvickers]

Note for triage: this is a request for delete orphans behavior without cascade delete behavior.

[ajcvickers]

@ajbeaven Historically we haven't seen many requests to be able to configure these things differently, but it is not unreasonable to be able to do so, so putting this on the backlog to consider for a future release.

One way to avoid the circular dependencies issue to to edit the database migration to not set cascade delete in the database, but still have it configured on the EF side. This means that if you have a parent and a child both loaded and the parent is deleted, then EF will delete the child as well. (If the child is not loaded, then it won't be deleted and the database will likely throw.) If you can live with this behavior, then it should result in the behavior you are after "delete orphans".

Another thing you could do is override SaveChanges to process any entities that have been severed from their parent and mark them as deleted. I wrote about this years ago for EF Classic, but the same principals can be applied to EF Core.

[ajbeaven]

Thanks for considering it @ajcvickers, and also for the suggestions - such a convenient blog post! I'll give that a go next week.

[ajbeaven]

Regarding your second suggestion, when severing the relationship, it looks like EF Core doesn't mark the child's parent navigation property to NULL like it appears EF Classic did. This makes identifying the child entities that will be deleted a bit more difficult. Is there another way you can think of to find these orphaned records?

The first suggestion worked well though - thanks for that!

[ajcvickers]

Note that starting with 3.0, this can be achieved by using context.ChangeTracker.DeleteOrphansTiming, but keeping this open to allow the two things to be configured differently in the model.

[maulik-modi]

@ajcvickers , Let say we have 2 entities;
Parent: Id, name,
Child: Id, name, ParentId(Mandatory); DeleteBehaviour is RESTRICT

When Parent Entity is updated from SPA App, it may have

• added Child Entities
• updated Child Entities
• deleted Child Entities

When I try to remove child entities loaded via parent.INCLUDE I get DbUpdateException as per https://docs.microsoft.com/en-us/ef/core/saving/cascade-delete

Parent
{
  ICollection<Child>
}

What would be the permanent solution?

[ajcvickers]

@maulik-modi Please open a new issue and attach a small, runnable project or post a small, runnable code listing that reproduces what you are seeing so that we can investigate.

[maulik-modi]

@ajcvickers, I have created new issue here with code sample #25241

[TAGC]

I think this is an enhancement our team could benefit from as well. I've been working on a task that involves updating many of our entity relationships to use DeleteBehavior.NoAction instead of DeleteBehavior.Cascade because it's safer if, for example, accidentally removing Completed from our OrderStatus enum table doesn't automatically cascade delete 95% of the records in the Order table.

After making these changes I found that some of our tests were failing, and this is because removing a dependent entity from a collection within the principal doesn't automatically mark it as deleted as I originally assumed. Instead, it replaces the foreign key property with a "conceptual null" and only deletes it if cascade deletion mode is enabled. The logic that removes the entity from the collection is part of our domain layer and has no knowledge/access to the DbContext, and even if it did it wouldn't seem right to have to explicitly call DbSet.Remove(removedEntity).

(sidenote: Pinky Pie doesn't strike me as the 4.0 GPA type)