#20932: Issues with model Manager and inheritance.
-------------------------------------+-------------------------------------
Reporter: loic84 | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by loic):
Replying to [comment:11 poleha]:
> I don't try to enforce anything in
[https://code.djangoproject.com/ticket/25897/ #25897], I simply want to
fix the existing approach, which doesn't work as expected.
Well there is no existing approach, just documentation that says one thing
and code that does another, but by making the code do as the docs says we
enforce the idea described in the docs.
Replying to [comment:11 poleha]:
> Do you suggest removing all the code about contributing managers to
models and simple use regular python inheritance?
Well not exactly, we still need to "copy" the manager over so they return
the correct model type. Currently we copy them for abstract and proxied
parents but not concrete parents. This actually leads to the weird case
where we also copy managers from the abstract parents of the concrete
parents (which is the issue described in this ticket).
> I must confess I like it and I thought of it many times while examining
the current approach. Python inheritance works well and it's predictable.
There's some login behind current approach, which is described in
[https://docs.djangoproject.com/en/dev/topics/db/managers/#custom-
managers-and-model-inheritance/ documentation], but I am not sure that it
worth breaking regular python mro.
I like it too. But if we go that way, we need to decide what to do with
the default manager creation logic, should we still create the `objects`
manager and have it aliased to `_default_manager` if there are no other
managers defined on the child model or any of its abstract parents?
If we don't create it, then we have a backwards incompatibility but with
some (maybe lots of) efforts it should be possible to add a deprecation
period. The upside is that it becomes easy to explain and reason about
since the behavior would now be consistent across all 3 types of
inheritances.
If we do create it, then we remain compatible at the expense of more
convoluted logic when deciding whether or not to create the `objects`
manager and more complicated rules in the documentation. We also make
`objects` a special case, because if an inherited custom manager is called
`objects` it will be overridden by a plain `models.Manager()` instance
(and only of the child model doesn't have any other declared manager on
itself or one of its abstract parents).
--
Ticket URL: <https://code.djangoproject.com/ticket/20932#comment:12>
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/064.4930eca9b5fc6e6230867adcdaf57813%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
