#18012: Propagate reverse foreign keys from proxy models to base class
-------------------------------------+-------------------------------------
     Reporter:  akaariai             |                    Owner:  charettes
         Type:                       |                   Status:  assigned
  Cleanup/optimization               |
    Component:  Database layer       |                  Version:  1.4
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:
     Keywords:                       |             Triage Stage:  Accepted
    Has patch:  1                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by akaariai):

 The place where "reverse relations to proxy models are only a Python
 thing" breaks is deletion of models. Deletion of a model that points to a
 proxy child of a concrete model will delete the concrete model, too.
 Another way to think of this is that the foreign key in the database
 representation is to the concrete model, hence the concrete model does
 have the related model set.

 Maybe we could either add a Meta method to get reverse relations from
 proxy children, or just document how to do this properly. This way, if you
 need to get the proxy children, there is some way to actually do that.

 Still, a generic solution to this problem might be something along the
 lines:
 {{{
    fk = models.ForeignKey(ConcreteModel,
 reverse_queryset=ProxyModel.objects.all())
 }}}
 This is a new thing to learn. But reverse_queryset would have other uses,
 too. You could for example use a custom queryset with custom methods, add
 annotations, order_by and so on to it. If you filter in the
 reverse_queryset, then there might be problems, but we could just document
 that you shouldn't do that. This would also fix
 Manager.use_for_related_fields flag issues (the flag doesn't work at all
 consistently).

 All this being said I don't feel at all strongly about this issue, and if
 nobody else does, then we should default to not change existing behavior.

--
Ticket URL: <https://code.djangoproject.com/ticket/18012#comment:14>
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 post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.bf86d321d47ca8e1692716fc2efb7d07%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to