mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-08-04 02:48:35 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

Fixed #12930, #12832, #11538 -- Refactored and merged the GeoDjango documentation into the rest of the Django docs.

Browse source 
git-svn-id: http://code.djangoproject.com/svn/django/trunk@12856 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Justin Bronn 2010-03-26 20:14:53 +00:00
parent 667ced2abc
commit 459c71e332
25 changed files with 7101 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

11
docs/topics/db/managers.txt
View file

@ -296,11 +296,12 @@ manager that Django creates for you -- either as a default manager on a model
with no managers, or to use temporarily when accessing related objects.
Sometimes this default class won't be the right choice. One example is in the
`django.contrib.gis` application that ships with Django itself. All `gis`
models must use a special manager class (``GeoManager``) because they need a
special queryset (``GeoQuerySet``) to be used for interacting with the
database. It turns out that models which require a special manager like this
need to use the same manager class wherever an automatic manager is created.
:mod:`django.contrib.gis` application that ships with Django itself. All ``gis``
models must use a special manager class (:class:`~django.contrib.gis.db.models.GeoManager`)
because they need a special queryset (:class:`~django.contrib.gis.db.models.GeoQuerySet`)
to be used for interacting with the database. It turns out that models which require
a special manager like this need to use the same manager class wherever an automatic
manager is created.
Django provides a way for custom manager developers to say that their manager
class should be used for automatic managers whenever it is the default manager