pre_delete should be sent before collecting ForeignKey relationships

[Waldemar Kornewald]

If you have:

class MyModel(Model):
    user = ForeignKey(User, related_name='my_models', null=True)

You can't use a pre_delete signal to set user.my_models.clear() because the check for the related models is done before the signal is sent. It would be great if that were done after sending the signal.

[James Bennett]

This feels like a symptom of a different problem, namely the inability to emulate anything other than ON DELETE CASCADE; if we had that you wouldn't be trying to use signals to do this.

[Ilya Semenov]

While it actually is a symptom of a different (yet unsolved!) problem, the original suggestion makes sense per se. It shouldn't be disregarded just because that will magically allow to do some (useful) unrelated things, right?

[Alexey Kinyov]

It seems, there's alternative approach for such usecase #12899, which I belive, is more consistent.

[cgieringer]

Adds a pre_signal argument to _collect_sub_objects to allow the notification of listeners to pre_deletes before related objects are collected.

[cgieringer]

I agree with the ticket creator that django should send the pre_delete signal at a time when it is still possible to modify the model in a way that affects deletion. It seems that the contract of all pre_xx signal should include informing listeners before any undoable changes have occurred in the deletion, save, etc.

The most common usage for a correctly behaving pre_delete signal is apparently to remove related objects to prevent cascade deletion, and the feature requested in #7539 would eventually provide another means to that usage. But that possible feature doesn't change the fact that pre_delete breaks its contract (or what it seems its contract should be) by collecting the related objects for deletion before informing listeners that the objects will be deleted, thereby offering no consistent way to prevent cascade deletion. The only way to get around this limitation is to define both a custom model delete and manager delete for each model requiring this functionality, which is a tedious and error-prone requirement.

Currently the pre_delete signal is sent from django.db.models.query.delete_objects. The least-complicated place to send the signal while meeting its contract is from the beginning of _collect_sub_objects, because this is both the first place that related objects are seen (as that method traverses relations from the original model) and the last place that a change to a model's related objects can be made before they are cached in seen_objects and then sent for deletion.

I have attached a patch which adds a pre_signal argument to django.db.model.base.Model's _collect_sub_objects. The argument should be one of Django's signals from django.db.models.signals, and it will be called at the beginning of the method if the model was not autocreated. The argument is called pre_signal because although _collect_sub_objects is presently only used for finding related objects for deletion, it could possibly be used for some other purpose for which a different pre_xx signal should be sent. The patch adds _collect_sub_objects(..., pre_signal=pre_signal) to recursions and _collect_sub_objects(..., pre_signal=pre_delete) to the two places the method is called. It removes the sending of pre_delete from delete_objects.

Thank you to all the Django developers, this framework is my favorite piece of software.

[cgieringer]

I added a test that deletes a model and asserts that another model with a foreign key to it had the opportunity to be rescued from deletion via a pre_delete signal

[cgieringer]

Removed "".format to make Python 2.4 compliant

[Carl Meyer]

Now that #7539 is fixed, the use-case scope here is reduced. Nevertheless, moving the signal to fire before related objects are collected is not particularly difficult, seems reasonable, and increases the usefulness of the signal. In my preliminary test, doing so causes only one test failure, and that is spurious (because pre_delete signal is being used to test the order of actual deletion).

The only concern I have here is the subtle backwards-incompatibility reflected by that test failure: pre-delete signals will now fire in a different order than previously. OTOH, the documentation makes no guarantees about order of pre_delete signals firing, and if anything the order after this change is more logical (it would now be the order of collection).

The patch will look quite different now that #7539 has landed. Here's an initial take on it, but I haven't yet resolved the failing deletion-order test: ​https://github.com/carljm/django/compare/master...t6870

[Julien Phalip]

See a possibly related feature request in #13251.

[jashugan]

The original use-case still exists for generic relations, which does not support the on_delete functionality given by #7593.

[Łukasz Langa]

There are more use-cases than that. One of those is Admin's object deletion. Let me give you an example:

I have a Team model and a Member model. Teams have Members. Trivial stuff. I also log every change on a Team or its Members by creating LogEntry objects. So, when a Member is deleted, I have a pre_delete signal that saves the LogEntry ("member parted") for the related Team. Now, when I try to delete a Team from the Admin, during deletion of existing Members, log entries are created by the pre_delete signal and the transaction fails.

Currently as a workaround you have to either let orphaned objects litter the DB by using on_delete or to create another pre_delete signal for the Team model which does instance.logentry_set.all().delete().

[anonymous]

I've run in the same problem, not easy to debug. I'd be great to see it fixed someday.

[Daniel Whitney]

Will this be addressed at any point? I've been running into this issue for the past month.