Changes between Initial Version and Version 1 of Ticket #23076, comment 23


Ignore:
Timestamp:
Jan 21, 2026, 1:59:26 PM (2 weeks ago)
Author:
Brian Kohan

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #23076, comment 23

    initial v1  
    11I 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.
    22
    3 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.
     3As 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 core collector logic robust to it.
Back to Top