| 1791 | | If you use custom ``Manager`` objects, take note that the first ``Manager`` |
|---|
| 1792 | | Django encounters (in order by which they're defined in the model) has a |
|---|
| 1793 | | special status. Django interprets the first ``Manager`` defined in a class as |
|---|
| 1794 | | the "default" ``Manager``. Certain operations -- such as Django's admin site -- |
|---|
| 1795 | | use the default ``Manager`` to obtain lists of objects, so it's generally a |
|---|
| 1796 | | good idea for the first ``Manager`` to be relatively unfiltered. In the last |
|---|
| 1797 | | example, the ``people`` ``Manager`` is defined first -- so it's the default |
|---|
| 1798 | | ``Manager``. |
|---|
| | 1791 | If you use custom ``Manager`` objects, take note that the first |
|---|
| | 1792 | ``Manager`` Django encounters (in the order in which they're defined |
|---|
| | 1793 | in the model) has a special status. Django interprets this first |
|---|
| | 1794 | ``Manager`` defined in a class as the "default" ``Manager``, and |
|---|
| | 1795 | several parts of Django (though not the admin application) will use |
|---|
| | 1796 | that ``Manager`` exclusively for that model. As a result, it's often a |
|---|
| | 1797 | good idea to be careful in your choice of default manager, in order to |
|---|
| | 1798 | avoid a situation where overriding of ``get_query_set()`` results in |
|---|
| | 1799 | an inability to retrieve objects you'd like to work with. |
|---|
