~ubuntu-branches/ubuntu/quantal/python-django/quantal-security

« back to all changes in this revision

Viewing changes to docs/topics/db/managers.txt

  • Committer: Bazaar Package Importer
  • Author(s): Chris Lamb
  • Date: 2010-05-21 07:52:55 UTC
  • mfrom: (1.3.6 upstream)
  • mto: This revision was merged to the branch mainline in revision 28.
  • Revision ID: james.westby@ubuntu.com-20100521075255-ii78v1dyfmyu3uzx
Tags: upstream-1.2
ImportĀ upstreamĀ versionĀ 1.2

Show diffs side-by-side

added added

removed removed

Lines of Context:
167
167
This example allows you to request ``Person.men.all()``, ``Person.women.all()``,
168
168
and ``Person.people.all()``, yielding predictable results.
169
169
 
170
 
If you use custom ``Manager`` objects, take note that the first
171
 
``Manager`` Django encounters (in the order in which they're defined
172
 
in the model) has a special status. Django interprets this first
173
 
``Manager`` defined in a class as the "default" ``Manager``, and
174
 
several parts of Django (though not the admin application) will use
175
 
that ``Manager`` exclusively for that model. As a result, it's often a
176
 
good idea to be careful in your choice of default manager, in order to
177
 
avoid a situation where overriding of ``get_query_set()`` results in
178
 
an inability to retrieve objects you'd like to work with.
 
170
If you use custom ``Manager`` objects, take note that the first ``Manager``
 
171
Django encounters (in the order in which they're defined in the model) has a
 
172
special status. Django interprets the first ``Manager`` defined in a class as
 
173
the "default" ``Manager``, and several parts of Django will use that ``Manager``
 
174
exclusively for that model. As a result, it's a good idea to be careful in
 
175
your choice of default manager in order to avoid a situation where overriding
 
176
``get_query_set()`` results in an inability to retrieve objects you'd like to
 
177
work with.
179
178
 
180
179
.. _managers-for-related-objects:
181
180
 
235
234
 
236
235
    class AbstractBase(models.Model):
237
236
        ...
238
 
        objects = CustomerManager()
 
237
        objects = CustomManager()
239
238
 
240
239
        class Meta:
241
240
            abstract = True
296
295
with no managers, or to use temporarily when accessing related objects.
297
296
 
298
297
Sometimes this default class won't be the right choice. One example is in the
299
 
`django.contrib.gis` application that ships with Django itself. All `gis`
300
 
models must use a special manager class (``GeoManager``) because they need a
301
 
special queryset (``GeoQuerySet``) to be used for interacting with the
302
 
database.  It turns out that models which require a special manager like this
303
 
need to use the same manager class wherever an automatic manager is created.
 
298
:mod:`django.contrib.gis` application that ships with Django itself. All ``gis``
 
299
models must use a special manager class (:class:`~django.contrib.gis.db.models.GeoManager`)
 
300
because they need a special queryset (:class:`~django.contrib.gis.db.models.GeoQuerySet`)
 
301
to be used for interacting with the database.  It turns out that models which require
 
302
a special manager like this need to use the same manager class wherever an automatic
 
303
manager is created.
304
304
 
305
305
Django provides a way for custom manager developers to say that their manager
306
306
class should be used for automatic managers whenever it is the default manager
333
333
As already suggested by the `django.contrib.gis` example, above, the
334
334
``use_for_related_fields`` feature is primarily for managers that need to
335
335
return a custom ``QuerySet`` subclass. In providing this functionality in your
336
 
manager, there are a couple of things to be remember and that's the topic of
337
 
this section.
 
336
manager, there are a couple of things to remember.
338
337
 
339
338
Do not filter away any results in this type of manager subclass
340
339
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~