#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 carljm):
Replying to [comment:14 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.
Deletion also cascades up MTI inheritance chains, but we don't hoist the
reverse descriptor for FKs to MTI child models onto the parent model. Do
you see something "broken" there also? I don't.
I don't think these two things (cascade deletion and the Python class on
which reverse descriptors live) are connected in the way you're
suggesting. The mental model for both types of inheritance (MTI and proxy)
is that any instance in a given inheritance chain really represents the
"same object" -- the non-leaf instances are just generic / incomplete
representations of that object. So naturally, if you delete that thing
it's gone (and of course that includes its incomplete representations).
There's nothing inconsistent with that mental model (or with the deletion
behavior, in either the proxy or MTI case) in having a reverse FK
descriptor on a child class that isn't there on the parent; it's just one
of (possibly many) ways in which a parent instance is an incomplete
representation of the full object.
> 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.
I'm not necessarily opposed to a feature like this if it has other uses
that can stand on their own to justify the feature, but for the specific
case of having an FK return proxy model instances, I think this API is a
step backwards in usability from just pointing the FK at the proxy model,
which already works fine.
--
Ticket URL: <https://code.djangoproject.com/ticket/18012#comment:15>
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.6b43686779d6329c1881ffbde018cf89%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
