#23076: Cascaded deletion of polymorphic models fails
-------------------------------------+-------------------------------------
Reporter: jernej@… | Owner: nobody
Type: Bug | Status: closed
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Brian Kohan):
* resolution: => wontfix
* status: new => closed
Comment:
I am the current maintainer of [https://github.com/jazzband/django-
polymorphic django-polymorphic]. I'm closing this ticket because this
issue has been fixed downstream in [https://github.com/jazzband/django-
polymorphic django-polymorphic] without needing to touch any Django
internals.
As explained in the [https://github.com/jazzband/django-
polymorphic/pull/746 downstream PR] there is nothing special about the
deletion of polymorphic querysets. The django deletion code traverses the
model graph both children and parents and deletes all of the necessary
rows in order. The operation is identical for polymorphic models, the
issue is that querysets returning subclasses of the queryset model was
confusing the graph traversal algorithm. It is therefore more appropriate
to modify custom querysets and wrap collectors for these special cases
than to make the default collector logic robust to it.
--
Ticket URL: <https://code.djangoproject.com/ticket/23076#comment:23>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019be1b9c177-7a5c8ef8-06e1-417a-b736-990eb13746e0-000000%40eu-central-1.amazonses.com.
