summaryrefslogtreecommitdiff
path: root/docs/topics/db
diff options
context:
space:
mode:
Diffstat (limited to 'docs/topics/db')
-rw-r--r--docs/topics/db/managers.txt11
1 files changed, 6 insertions, 5 deletions
diff --git a/docs/topics/db/managers.txt b/docs/topics/db/managers.txt
index d7f5569c91..4569775652 100644
--- a/docs/topics/db/managers.txt
+++ b/docs/topics/db/managers.txt
@@ -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