Cannot delete or update a parent row: a foreign key constraint fails

[thenewguy]

Using the delete_selected admin action can cause an error similar to the following:

IntegrityError: (1451, 'Cannot delete or update a parent row: a foreign key constraint fails (foo2.bar, CONSTRAINT format_ptr_id_refs_id_270cb9d612063f8e FOREIGN KEY (format_ptr_id) REFERENCES foo1 (id))')

[vdboor]

Hi, can you tell me how to reproduce this issue? I've tried everything in the example project, and didn't get this issue.

[dsaradini]

Hello,

We have the same issue when deleting list of polymorphic elements.
What is strange is that, when running tests, we are unable to reproduce the problem. ( no constraint violations )

Here is the example

1. we have an "Group" object containing Question objects of 3 types ( "Rating" "FreeText" and "Choice" all subclass of "Question").
2. "Question" holds the ForeignKey on "Group".
   3a) If we create a "Group" with all questions of the same type, deleting the "Group" works fine.
   3b) If we create mixed "Question" types ( one FreeText and one Rating in this case ), deleting the "Group" will fail with the following error "update or delete on table "sample_question" violates foreign key constraint "questionptr_id_refs_id_b59c6fec" on table "sample_rating""

We are using postgresql and it seems that the delete statements generated during the delete will depend on the FIRST type found in the deleted list.

• DELETE FROM "sample_freetext" WHERE "question_ptr_id" IN (3, 2, 1)
• DELETE FROM "sample_group" WHERE "id" IN (1)
• DELETE FROM "sample_question" WHERE "id" IN (3, 2, 1)
• COMMIT --> ERROR ( show above )

"sample_rating" elements are never deleted. Indeed, if we create a test, the result of Rating.objects.count(), will be 1 NOT 0.

If we create Rating first, then FreeText, it is the "sample_freetext" that is never delete...

As soon as we have time, we will investigating the code, to see where ( and how ) the delete query set is "generate".

[chrisglass]

Hum that is very strange. I will look as well.

[chrisglass]

@dsaradini you mention writing a test for it - would you mind sharing it in a gist or as a PR?
What version of the software are you running? Can you try using trunk if you're using a released version?

[dsaradini]

@chrisglass We're using the Pypi version 0.5.1. I will try with the trunk as soon as I have a moment, and also provide a running code that demonstrate the problem.

[stephrdev]

We tracked down the error to a problem in the deletion collector of the Django ORM.

The first problem is django/db/models/deletion.py:102. This method assumes that all objects in the list are the same model class (which is correct, if you use the normal Django manager). django-polymorphic is different. Therefore the code adds all objects with the first model class it finds in the list of objects.

The objects which get passed to the add method are fetched in the related_objects method (line 240, same file). This method uses _base_manager of the related model (which is the base model of the multitable model construction).

We fixed this bug by manually adding a _base_manager = models.Manager() to the PolymorhpicModel subclass, but this doesn't feel right.

Another note: this only happens with foreignkeys/relations on the polymorphic base model. If you have foreignkeys in one of the submodels, everything works just fine. Hope the remarks help to find a clean solution for this issue.

[vdboor]

Thanks @stephrdev for the great help here. Can you post some example code (or gist) to demonstrate this issue? I'd love to fire up a project in the debugger to figure this out, but am keenly looking for model code.

[vdboor]

I also ran into this issue today, and it was caused by a GenericRelation object on the model. The collector has special code for that. I fixed it in my code by returning the non-polymorphic query:

class ContentItemRelation(GenericRelation):
    def __init__(self, **kwargs):
        super(ContentItemRelation, self).__init__(to=ContentItem,
            object_id_field='parent_id', content_type_field='parent_type', **kwargs)

    def bulk_related_objects(self, objs, using=DEFAULT_DB_ALIAS):
        # Fix delete screen. Workaround for https://github.com/chrisglass/django_polymorphic/issues/34
        return super(ContentItemRelation, self).bulk_related_objects(objs).non_polymorphic()

Again guys, please provide a usable example project. My situation can be completely different from yours, so I won't be able to track all edge-cases without an example project.

[habfast]

I ran into the problem today. What is the status?

[svengt]

I am also running into this problem, is the GenericRelation still a valid solution? The documentation of Django says this object is deprecated since 1.7 and will be completely removed in 1.9.

[mlncn]

The _base_manager = Manager() fix from @stephrdev worked for us too. Seems something in the PolymorphicModel's manager isn't quite right?

[egamonal]

mincn, can you elaborate more about that solution?
I'm having the same problem with version 0.6.1.
I have a polymorphic class called Action, which has a foreign key to Campaign. I can't delete campaigns from the admin view because this integrity error raises. I have to delete the child classes first.

so far I fixed the issue with a pre_delete signal in the Campaign class. I iterate over the relation and delete objects one at a time. I guess it's awful for performance, but at least it works.

[jmurty]

We have encountered this issue and chased it down to a bug in Django core's handling of reverse M2M relationships that target proxy models. In brief, the issue isn't specific to polymorphic but affects Django as well. It's probably just much more likely to occur if you use polymorphic.

We have followed up in the relevant Django Track ticket: https://code.djangoproject.com/ticket/23076

Also created a new, more specific Django ticket: https://code.djangoproject.com/ticket/25520

[vdboor]

Thanks a lot - that really helps!

[jmurty]

Because others continue to struggle with this I have created a gist of the (truly awful and hacky) work-around we are using for this issue, which monkey-patches Django's deletion collector to include proxy models: https://gist.github.com/jmurty/2034c24b6f91a3eaf51a

I had intended to package this up more nicely in an installable project and include some related unit tests we have, but as always it's been hard to find the time.

Please read the comments in that gist and use at your own risk. It works for us... for you, maybe not so much.