Question

I have a ForeignKey which can be null in my model to model a loose coupling between the models. It looks somewhat like that:

class Message(models.Model):   sender = models.ForeignKey(User, null=True, blank=True)   sender_name = models.CharField(max_length=255) 

On save the senders name is written to the sender_name attribute. Now, I want to be able to delete the User instance referenced by the sender and leave the message in place.

Out of the box, this code always results in deleted messages as soon as I delete the User instance. So I thought a signal handler would be a good idea.

def my_signal_handler(sender, instance, **kwargs):   instance.message_set.clear() pre_delete.connect(my_signal_handler, sender=User) 

Sadly, it is by no means a solution. Somehow Django first collects what it wants to delete and then fires the pre_delete handler.

Any ideas? Where is the knot in my brain?

Answer 1

Django does indeed emulate SQL’s ON DELETE CASCADE behaviour, and there’s no out-of-the box documented way to change this. The docs where they mention this are near the end of this section: Deleting objects.

You are right that Django’s collects all related model instances, then calls the pre-delete handler for each. The sender of the signal will be the model class about to be deleted, in this case Message, rather than User, which makes it hard to detect the difference between a cascade delete triggered by User and a normal delete… especially since the signal for deleting the User class comes last, since that’s the last deletion 🙂

You can, however, get the list of objects that Django is proposing to delete in advance of calling the User.delete() function. Each model instance has a semi-private method called _collect_sub_objects() that compiles the list of instances with foreign keys pointing to it (it compiles this list without deleting the instances). You can see how this method is called by looking at delete() in django.db.base.

If this was one of your own objects, I’d recommend overriding the delete() method on your instance to run _collect_sub_objects(), and then break the ForeignKeys before calling the super class delete. Since you’re using a built-in Django object that you may find too difficult to subclass (though it is possible to substitute your own User object for django’s), you may have to rely on view logic to run _collect_sub_objects and break the FKs before deletion.

Here’s a quick-and-dirty example:

from django.db.models.query import CollectedObjects u = User.objects.get(id=1)   instances_to_be_deleted = CollectedObjects() u._collect_sub_objects(instances_to_be_deleted)  for k in instances_to_be_deleted.ordered_keys():     inst_dict = instances_to_be_deleted.data[k]     for i in inst_dict.values():         i.sender = None  # You will need a more generic way for this         i.save()  u.delete()