99
Just a note for those who run into this issue as well, there is now an built-in solution in Django 1.3.
See the details in the documentation django.db.models.ForeignKey.on_delete Thanks for editor of Fragments of Code site to point it out.
The simplest possible scenario just add in your model FK field definition:
on_delete=models.SET_NULL
7
Django only emulates CASCADE behaviour.
According to discussion in Django Users Group the most adequate solutions are:
- To repeat ON DELETE SET NULL scenario – manually do obj.rel_set.clear() (for every related model) before obj.delete().
- To repeat ON DELETE RESTRICT scenario – manually check is obj.rel_set empty before obj.delete().
- [Django]-Django – Reverse for '' not found. '' is not a valid view function or pattern name
- [Django]-Django: Reverse for 'detail' with arguments '('',)' and keyword arguments '{}' not found
- [Django]-Django: using <select multiple> and POST
6
Ok, the following is the solution I’ve settled on, though it’s far from satisfying.
I’ve added an abstract base class for all my models:
class MyModel(models.Model):
class Meta:
abstract = True
def pre_delete_handler(self):
pass
A signal handler catches any pre_delete
events for subclasses of this model:
def pre_delete_handler(sender, instance, **kwargs):
if isinstance(instance, MyModel):
instance.pre_delete_handler()
models.signals.pre_delete.connect(pre_delete_handler)
In each of my models, I simulate any “ON DELETE RESTRICT
” relations by throwing an exception from the pre_delete_handler
method if a child record exists.
class RelatedRecordsExist(Exception): pass
class SomeModel(MyModel):
...
def pre_delete_handler(self):
if children.count():
raise RelatedRecordsExist("SomeModel has child records!")
This aborts the delete before any data is modified.
Unfortunately, it is not possible to update any data in the pre_delete signal (e.g. to emulate ON DELETE SET NULL
) as the list of objects to delete has already been generated by Django before the signals are sent. Django does this to avoid getting stuck on circular references and to prevent signaling an object multiple times unnecessarily.
Ensuring a delete can be performed is now the responsibility of the calling code. To assist with this, each model has a prepare_delete()
method that takes care of setting keys to NULL
via self.related_set.clear()
or similar:
class MyModel(models.Model):
...
def prepare_delete(self):
pass
To avoid having to change too much code in my views.py
and models.py
, the delete()
method is overridden on MyModel
to call prepare_delete()
:
class MyModel(models.Model):
...
def delete(self):
self.prepare_delete()
super(MyModel, self).delete()
This means that any deletes explicitly called via obj.delete()
will work as expected, but if a delete has cascaded from a related object or is done via a queryset.delete()
and the calling code hasn’t ensured that all links are broken where necessary, then the pre_delete_handler
will throw an exception.
And lastly, I’ve added a similar post_delete_handler
method to the models that gets called on the post_delete
signal and lets the model clear up any other data (for example deleting files for ImageField
s.)
class MyModel(models.Model):
...
def post_delete_handler(self):
pass
def post_delete_handler(sender, instance, **kwargs):
if isinstance(instance, MyModel):
instance.post_delete_handler()
models.signals.post_delete.connect(post_delete_handler)
I hope that helps someone and that the code can be re-threaded back into something more useable without too much trouble.
Any suggestions on how to improve this are more than welcome.
- [Django]-Django: change the value of a field for all objects in a queryset
- [Django]-How to revert the last migration?
- [Django]-What the difference between using Django redirect and HttpResponseRedirect?