Allow delete fixup and cascade timing to be configured #10114
Comments
|
Another use case here: Being able to detect the entities that were removed (possibly by getting a tree of them prior to SaveChanges) so that you can perform an action afterwards. For example, removing referenced objects from the filesystem or S3. |
Should the same behaviour occur when query filters are applied such as when doing a soft delete? For example in a Blog/Posts scenario, if a Post is soft deleted (using shadow property and query filter), the Post no longer appears in the DbSet, but I still see it in the navigation collection of the Blog. |
ajcvickers
added
propose-punt
breaking-change
and removed
size~3-days
propose-punt
labels
|
My 2 cents - my primary interest is in soft delete. I check which entities have been deleted, and instead set an IsDeleted=true and change them to Modified. It would suffice for me to just get some kind of callback where I can do this logic. Since you said the current logic is in order to do the right thing for reparenting, and prevent graph shredding, I don't necessarily want that just undone in the general case. All I need is some point where I get the REAL state of the objects prior to the DB save... |
Fixes #10114 Allows timing cascade delete (i.e. delete of dependent on principal deletion) and delete orphans (i.e. delete of dependent on severing its relationship to the principal) to be configured as: * Immediate: Dependents changed to Deleted immediately, or at least at the next DetectChanges * OnSaveChanges: Dependents are not changed to Deleted until SaveChanges is called * Never: Cascades don't happen automatically. They can be triggered by a new method: `context.ChangeTracker.CascadeChanges()` The default for both has been changed to `Immediate` which is a breaking change, but likely a better default because: * Auditing in overridden SaveChanges will now report anything that will be deleted * Data binding will reflect the changes immediately However, deleting orphans can be more difficult. This doesn't appear to be a major problem in EF Core because we don't aggressively graph shred, we don't typically have entities that handle their own fixup, and conceptual nulls still exist to allow transitionary states. Note that EF6 does not support deleting orphans, which means the behavior here with both set to Immediate is not quite the same as the default behavior of EF6.
Fixes #10114 Allows timing cascade delete (i.e. delete of dependent on principal deletion) and delete orphans (i.e. delete of dependent on severing its relationship to the principal) to be configured as: * Immediate: Dependents changed to Deleted immediately, or at least at the next DetectChanges * OnSaveChanges: Dependents are not changed to Deleted until SaveChanges is called * Never: Cascades don't happen automatically. They can be triggered by a new method: `context.ChangeTracker.CascadeChanges()` The default for both has been changed to `Immediate` which is a breaking change, but likely a better default because: * Auditing in overridden SaveChanges will now report anything that will be deleted * Data binding will reflect the changes immediately However, deleting orphans can be more difficult. This doesn't appear to be a major problem in EF Core because we don't aggressively graph shred, we don't typically have entities that handle their own fixup, and conceptual nulls still exist to allow transitionary states. Note that EF6 does not support deleting orphans, which means the behavior here with both set to Immediate is not quite the same as the default behavior of EF6.
ajcvickers
added
the
closed-fixed
Fixes #10114 Allows timing cascade delete (i.e. delete of dependent on principal deletion) and delete orphans (i.e. delete of dependent on severing its relationship to the principal) to be configured as: * Immediate: Dependents changed to Deleted immediately, or at least at the next DetectChanges * OnSaveChanges: Dependents are not changed to Deleted until SaveChanges is called * Never: Cascades don't happen automatically. They can be triggered by a new method: `context.ChangeTracker.CascadeChanges()` The default for both has been changed to `Immediate` which is a breaking change, but likely a better default because: * Auditing in overridden SaveChanges will now report anything that will be deleted * Data binding will reflect the changes immediately However, deleting orphans can be more difficult. This doesn't appear to be a major problem in EF Core because we don't aggressively graph shred, we don't typically have entities that handle their own fixup, and conceptual nulls still exist to allow transitionary states. Note that EF6 does not support deleting orphans, which means the behavior here with both set to Immediate is not quite the same as the default behavior of EF6.
Fixes #10114 Allows timing cascade delete (i.e. delete of dependent on principal deletion) and delete orphans (i.e. delete of dependent on severing its relationship to the principal) to be configured as: * Immediate: Dependents changed to Deleted immediately, or at least at the next DetectChanges * OnSaveChanges: Dependents are not changed to Deleted until SaveChanges is called * Never: Cascades don't happen automatically. They can be triggered by a new method: `context.ChangeTracker.CascadeChanges()` The default for both has been changed to `Immediate` which is a breaking change, but likely a better default because: * Auditing in overridden SaveChanges will now report anything that will be deleted * Data binding will reflect the changes immediately However, deleting orphans can be more difficult. This doesn't appear to be a major problem in EF Core because we don't aggressively graph shred, we don't typically have entities that handle their own fixup, and conceptual nulls still exist to allow transitionary states. Note that EF6 does not support deleting orphans, which means the behavior here with both set to Immediate is not quite the same as the default behavior of EF6.
Fixes #10114 Allows timing cascade delete (i.e. delete of dependent on principal deletion) and delete orphans (i.e. delete of dependent on severing its relationship to the principal) to be configured as: * Immediate: Dependents changed to Deleted immediately, or at least at the next DetectChanges * OnSaveChanges: Dependents are not changed to Deleted until SaveChanges is called * Never: Cascades don't happen automatically. They can be triggered by a new method: `context.ChangeTracker.CascadeChanges()` The default for both has been changed to `Immediate` which is a breaking change, but likely a better default because: * Auditing in overridden SaveChanges will now report anything that will be deleted * Data binding will reflect the changes immediately However, deleting orphans can be more difficult. This doesn't appear to be a major problem in EF Core because we don't aggressively graph shred, we don't typically have entities that handle their own fixup, and conceptual nulls still exist to allow transitionary states. Note that EF6 does not support deleting orphans, which means the behavior here with both set to Immediate is not quite the same as the default behavior of EF6.
|
Re-opening to ensure breaking change is announced. |
|
What was the conclusion with regard to fixing up navigation properties to no longer reference deleted entities before SaveChanges? i.e. This part of the original issue:
As far as I can tell deleted entities are only removed from navigation properties after SaveChanges. |
|
@markhobson That part of the changed proved problematic and very breaking. Cascade of states happens immediately by default, but fixup only of navigations only happens after the entity is really deleted by SaveChanges. |
|
Thanks for clarifying. |
|
@ajcvickers I am using EF Core 3.1. Configuration: Delete method: However, in save changes I am getting And in the SaveChanges I see that Suggestion entity is not Deleted but Modified. I see that it is the same problem as in this issue, could be it an ef core bug? |
|
@deivyd321 |
|
@ajcvickers thanks for reply. But I don't want to delete the principal entity. The principal entity contains many So I think |
|
Thanks for all the hard work that went into EF.Core. Is there a way to achieve a similar outcome without calling |
|
Hello everybody, we are also in the same situation as @TOuhrouche. "When an entity is deleted, it also gets removed from all navigation properties without calling SaveChanges" So I'm also wondering if there is a way to be able to achieve this behavior? @TOuhrouche did you find a solution in the meantime ? I appreciate any of your feedback |
@ajcvickers - could you explain why this was problematic? I'm thinking about doing something about this for our own purposes, but if you already have good reasons why one should not do this then I'd prefer not to waste the time :-) |
What are you thinking of doing? |
Automatic fixup 😊 Specifically when doing context.Add/remove we're looking into handling navigation properties on "neighboring" entities. Eg table A and B are "joined" by table C (one-to-many on one side, one-to-one on the other). When a C is added to the context (eg context.Add) we'll automatically add C to navigation properties A.ListOfManyCs (List) and B.MyC. Same when removed, but obviously removed from each navigation property. Same when moved (but less of a use case for us). |
|
@cjblomqvist EF Core already does this. |
|
Hmm I see. I interpreted #23940 like it wasn't/won't be (before SaveChanges). I created a repro based on an example in that issue, but maybe I'm missing something/there's something wrong with the code? (or maybe I was unclear that I meant before SaveChanges) |
|
@cjblomqvist For deleted entities, this is tracked by #29486. |
One can find our solution here: #29486 (comment) |
Currently:
However, there are scenarios where it is useful for these things to happen at different times:
There are a few things we could do:
The text was updated successfully, but these errors were encountered: