Fixed #13035 - Incorrect documentation regarding admin and default managers
Thanks to rasca for report and gabrielhurley for patch git-svn-id: http://code.djangoproject.com/svn/django/trunk@12930 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
671f848dd1
commit
f7814cdfe6
|
@ -167,15 +167,14 @@ For example::
|
||||||
This example allows you to request ``Person.men.all()``, ``Person.women.all()``,
|
This example allows you to request ``Person.men.all()``, ``Person.women.all()``,
|
||||||
and ``Person.people.all()``, yielding predictable results.
|
and ``Person.people.all()``, yielding predictable results.
|
||||||
|
|
||||||
If you use custom ``Manager`` objects, take note that the first
|
If you use custom ``Manager`` objects, take note that the first ``Manager``
|
||||||
``Manager`` Django encounters (in the order in which they're defined
|
Django encounters (in the order in which they're defined in the model) has a
|
||||||
in the model) has a special status. Django interprets this first
|
special status. Django interprets the first ``Manager`` defined in a class as
|
||||||
``Manager`` defined in a class as the "default" ``Manager``, and
|
the "default" ``Manager``, and several parts of Django will use that ``Manager``
|
||||||
several parts of Django (though not the admin application) will use
|
exclusively for that model. As a result, it's a good idea to be careful in
|
||||||
that ``Manager`` exclusively for that model. As a result, it's often a
|
your choice of default manager in order to avoid a situation where overriding
|
||||||
good idea to be careful in your choice of default manager, in order to
|
``get_query_set()`` results in an inability to retrieve objects you'd like to
|
||||||
avoid a situation where overriding of ``get_query_set()`` results in
|
work with.
|
||||||
an inability to retrieve objects you'd like to work with.
|
|
||||||
|
|
||||||
.. _managers-for-related-objects:
|
.. _managers-for-related-objects:
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue