37π
No, the documentation doesnβt say that. What it says is that if you define a GenericRelation
on a model β ie the reverse side of the GenericForeignKey
β then when the item with the generic FK is deleted, the item with the GenericRelation will also be deleted.
Unlike ForeignKey, GenericForeignKey does not accept an on_delete
argument to customize this behavior; if desired, you can avoid the
cascade-deletion simply by not using GenericRelation, and alternate
behavior can be provided via the pre_delete signal.
15π
I realise this is a very old question so itβs possible things are different from when this was asked, but the accepted answer had me chasing down a rabbit hole this morning, therefore I wanted to leave this here to prevent future generations sharing my pain.
From the docs:
Note also, that if you delete an object that has a GenericRelation, any objects which have a GenericForeignKey pointing at it will be deleted as well. In the example above, this means that if a Bookmark object were deleted, any TaggedItem objects pointing at it would be deleted at the same time.
This is the opposite of what the accepted answer is saying. Imagine the following:
class Comment(models.Model):
body = models.TextField(verbose_name='Comment')
user = models.ForeignKey(User, on_delete=models.CASCADE)
content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)
object_id = models.PositiveIntegerField()
content_object = generic.GenericForeignKey('content_type', 'object_id')
class Post(models.Model):
comment = GenericRelation(Comment)
In the above example, if your Comment object has a Generic Foreign Key pointing to a Post object, then when the Post object is deleted any Comment objects pointing to it will also be deleted.
This is the expected behaviour and operates the same as a normal ForeignKey. Using the same example above, if the User object that the Comment object points to is deleted, the Comment will also be deleted.
If you happen to chance across this question because you need the reverse of this behaviour, i.e. when you delete the Comment the Post is also deleted, then you will likely need to employ the power of signals.
- [Django]-Django: Model Form "object has no attribute 'cleaned_data'"
- [Django]-Django: Support for string view arguments to url() is deprecated and will be removed in Django 1.10
- [Django]-Want to disable signals in Django testing
3π
In addition to previous answers β if you have more complex structure and something like GenericOneToOne
(which is not present in straight way in Django):
class Post(models.Model)
title = models.CharField(max_length=100)
class Comment(models.Model):
post = models.ForeignKey(Post)
body = models.TextField(verbose_name='Comment')
content_type = models.ForeignKey(ContentType)
object_id = models.PositiveIntegerField()
content_object = generic.GenericForeignKey('content_type', 'object_id')
class Meta:
# Constrain equals to OneToOne relation.
unique_together = ('content_type', 'object_id')
class Author(models.Model):
comment = GenericRelation(Comment)
name = models.CharField(max_length=100)
And you want to delete Post
and be sure that Comment
and Author
are deleted as well you need to write custom post_delete
signal:
from django.db.models.signals import post_delete
from django.dispatch import receiver
@receiver(post_delete, sender=Comment, dispatch_uid='delete_comment_content_object')
def delete_comment_content_object(sender, instance, using, **kwargs):
instance.content_object.delete()
If you override delete
method of Comment
class like this:
def delete(self, *args, **kwargs):
self.content_object.delete()
super().delete(args, kwargs)
It will delete Author
only if you delete Comment
. If you delete Post
Author
object will stay in database.
- [Django]-How to reload modules in django shell?
- [Django]-Django admin sort foreign key field list
- [Django]-Disable migrations when running unit tests in Django 1.7