#26749: Different manager for _base_manager and related descriptors
-------------------------------------+-------------------------------------
Reporter: spectras | Owner: nobody
Type: Uncategorized | Status: new
Component: Database layer | Version: 1.10
(models, ORM) |
Severity: Normal | Resolution:
Keywords: manager | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by loic):
> Could it be possible to clarify the intended use of exhaustive?
I was originally planning to document the exhaustive list of base manager
usages, but Tim actually wrote the docs for that patch and went with a
terser description. I'm not against adding a bit more details, patch
welcome.
> since the changes of the linked commits, it's now also used for related
fields, but hopefully that should be gone or overridable soon
The previous implementation of one-related descriptors weren't
representative of intent:
- The forward M2O descriptor had its own logic with regards to
`use_for_related_fields` because its implementation predated the
introduction of `_base_manager`
(7d9b29a56ddc1a793a02d55743c372a8256b97aa).
- The reverse O2O descriptor as originally implemented **only used**
`_base_manager` until I changed it in Django 1.8
(e043aae9bb2e3fa244f59b07fc16f57476cb80ff).
In practice `use_for_related_fields` meant "the default manager can also
be used as base manager" since the introduction of `_base_manager`, as
demonstrated by your need to monkeypatch `_base_manager` back to a plain
manager during the class preparation. Also `_base_manager` was introduced
to generalize the `use_for_related_fields` mechanism as documented in the
[https://github.com/django/django/commit/292f503845401868ae9bf02b9bb1c38f35774c2c
#diff-f291b9c8a76d4ccc6c2aa3708b27b251R270 historical note] that was
commited the same day `_base_manager` was introduced.
> My understanding is use cases 1-3 are internal uses, and are the
intended users of the base manager.
I don't see a distinction between internal and external use. There is
nothing internal about the concept of inserting data and/or wanting to
guarantee unfiltered results (e.g. dumpdata, collection for deletion,
etc.), and for that you'd want to use a plain manager. Granted those are
low-level operations that most projects don't need to worry about, but
3rd-party libraries are definitely among the intended users.
> The change you suggest, with related_manager_name, seems in line with my
understanding? If so, should GenericForeignKey use it as well?
Definitely, GenericForeignKey and GenericRelation actually don't pick the
most adequate managers due to their reliance on the
`get_object_for_this_type` and `get_all_objects_for_this_type` utilities
which use `_base_manager`. I'm planning to undocument these and remove
every usage in Django (deprecating them would break
[https://github.com/search?q=get_object_for_this_type&type=Code&utf8=%E2%9C%93
too much working code]) in favor of
[https://github.com/django/django/commit/37564b084b4a8f64fefd4af98eb0a4bd13258311
inlining their code].
> (by the way, in the ​default manager documentation, I thinkg it should
say default_manager_name instead of base_manager_name?)
Well spotted, want to make a patch?
--
Ticket URL: <https://code.djangoproject.com/ticket/26749#comment:5>
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.90f0904c8c9ffc0ebe14e27ddd7165ae%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
