Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Fixed #14841 -- added xrefs to topics/db/models. Thanks adamv.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@14837 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit ffa4badbd89412e28323e89ea7980c6b5f4bc5a3 1 parent 4800b46
Simon Meers authored December 05, 2010

Showing 1 changed file with 35 additions and 32 deletions. Show diff stats Hide diff stats

  1. 67  docs/topics/db/models.txt
67  docs/topics/db/models.txt
@@ -115,8 +115,8 @@ determine a few things:
115 115
 
116 116
     * The database column type (e.g. ``INTEGER``, ``VARCHAR``).
117 117
 
118  
-    * The widget to use in Django's admin interface, if you care to use it
119  
-      (e.g. ``<input type="text">``, ``<select>``).
  118
+    * The :doc:`widget </ref/forms/widgets>` to use in Django's admin interface,
  119
+      if you care to use it (e.g. ``<input type="text">``, ``<select>``).
120 120
 
121 121
     * The minimal validation requirements, used in Django's admin and in
122 122
       automatically-generated forms.
@@ -492,9 +492,10 @@ disabled for many-to-many relationships that use an intermediate model.
492 492
 The only way to create this type of relationship is to create instances of the
493 493
 intermediate model.
494 494
 
495  
-The ``remove`` method is disabled for similar reasons. However, the
496  
-``clear()`` method can be used to remove all many-to-many relationships
497  
-for an instance::
  495
+The :meth:`~django.db.models.fields.related.RelatedManager.remove` method is
  496
+disabled for similar reasons. However, the
  497
+:meth:`~django.db.models.fields.related.RelatedManager.clear` method can be
  498
+used to remove all many-to-many relationships for an instance::
498 499
 
499 500
     # Beatles have broken up
500 501
     >>> beatles.members.clear()
@@ -972,8 +973,8 @@ right).
972 973
 So a child model does not have access to its parent's :ref:`Meta
973 974
 <meta-options>` class. However, there are a few limited cases where the child
974 975
 inherits behavior from the parent: if the child does not specify an
975  
-:attr:`django.db.models.Options.ordering` attribute or a
976  
-:attr:`django.db.models.Options.get_latest_by` attribute, it will inherit
  976
+:attr:`~django.db.models.Options.ordering` attribute or a
  977
+:attr:`~django.db.models.Options.get_latest_by` attribute, it will inherit
977 978
 these from its parent.
978 979
 
979 980
 If the parent has an ordering and you don't want the child to have any natural
@@ -989,12 +990,12 @@ Inheritance and reverse relations
989 990
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
990 991
 
991 992
 Because multi-table inheritance uses an implicit
992  
-:class:`~django.db.models.fields.OneToOneField` to link the child and
  993
+:class:`~django.db.models.OneToOneField` to link the child and
993 994
 the parent, it's possible to move from the parent down to the child,
994 995
 as in the above example. However, this uses up the name that is the
995 996
 default :attr:`~django.db.models.ForeignKey.related_name` value for
996  
-:class:`django.db.models.fields.ForeignKey` and
997  
-:class:`django.db.models.fields.ManyToManyField` relations.  If you
  997
+:class:`~django.db.models.ForeignKey` and
  998
+:class:`~django.db.models.ManyToManyField` relations.  If you
998 999
 are putting those types of relations on a subclass of another model,
999 1000
 you **must** specify the
1000 1001
 :attr:`~django.db.models.ForeignKey.related_name` attribute on each
@@ -1002,7 +1003,7 @@ such field. If you forget, Django will raise an error when you run
1002 1003
 :djadmin:`validate` or :djadmin:`syncdb`.
1003 1004
 
1004 1005
 For example, using the above ``Place`` class again, let's create another
1005  
-subclass with a :class:`~django.db.models.fields.ManyToManyField`::
  1006
+subclass with a :class:`~django.db.models.ManyToManyField`::
1006 1007
 
1007 1008
     class Supplier(Place):
1008 1009
         # Must specify related_name on all relations.
@@ -1013,11 +1014,11 @@ Specifying the parent link field
1013 1014
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1014 1015
 
1015 1016
 As mentioned, Django will automatically create a
1016  
-:class:`~django.db.models.fields.OneToOneField` linking your child
  1017
+:class:`~django.db.models.OneToOneField` linking your child
1017 1018
 class back any non-abstract parent models. If you want to control the
1018 1019
 name of the attribute linking back to the parent, you can create your
1019  
-own :class:`~django.db.models.fields.OneToOneField` and set
1020  
-:attr:`parent_link=True <django.db.models.fields.OneToOneField.parent_link>`
  1020
+own :class:`~django.db.models.OneToOneField` and set
  1021
+:attr:`parent_link=True <django.db.models.OneToOneField.parent_link>`
1021 1022
 to indicate that your field is the link back to the parent class.
1022 1023
 
1023 1024
 .. _proxy-models:
@@ -1045,8 +1046,9 @@ Proxy models are declared like normal models. You tell Django that it's a
1045 1046
 proxy model by setting the :attr:`~django.db.models.Options.proxy` attribute of
1046 1047
 the ``Meta`` class to ``True``.
1047 1048
 
1048  
-For example, suppose you want to add a method to the standard ``User`` model
1049  
-that will be used in your templates. You can do it like this::
  1049
+For example, suppose you want to add a method to the standard
  1050
+:class:`~django.contrib.auth.models.User` model that will be used in your
  1051
+templates. You can do it like this::
1050 1052
 
1051 1053
     from django.contrib.auth.models import User
1052 1054
 
@@ -1058,37 +1060,38 @@ that will be used in your templates. You can do it like this::
1058 1060
             ...
1059 1061
 
1060 1062
 The ``MyUser`` class operates on the same database table as its parent
1061  
-``User`` class. In particular, any new instances of ``User`` will also be
1062  
-accessible through ``MyUser``, and vice-versa::
  1063
+:class:`~django.contrib.auth.models.User` class. In particular, any new
  1064
+instances of :class:`~django.contrib.auth.models.User` will also be accessible
  1065
+through ``MyUser``, and vice-versa::
1063 1066
 
1064 1067
     >>> u = User.objects.create(username="foobar")
1065 1068
     >>> MyUser.objects.get(username="foobar")
1066 1069
     <MyUser: foobar>
1067 1070
 
1068 1071
 You could also use a proxy model to define a different default ordering on a
1069  
-model. The standard ``User`` model has no ordering defined on it
1070  
-(intentionally; sorting is expensive and we don't want to do it all the time
1071  
-when we fetch users). You might want to regularly order by the ``username``
1072  
-attribute when you use the proxy. This is easy::
  1072
+model. The standard :class:`~django.contrib.auth.models.User` model has no
  1073
+ordering defined on it (intentionally; sorting is expensive and we don't want
  1074
+to do it all the time when we fetch users). You might want to regularly order
  1075
+by the ``username`` attribute when you use the proxy. This is easy::
1073 1076
 
1074 1077
     class OrderedUser(User):
1075 1078
         class Meta:
1076 1079
             ordering = ["username"]
1077 1080
             proxy = True
1078 1081
 
1079  
-Now normal ``User`` queries will be unordered and ``OrderedUser`` queries will
1080  
-be ordered by ``username``.
  1082
+Now normal :class:`~django.contrib.auth.models.User` queries will be unordered
  1083
+and ``OrderedUser`` queries will be ordered by ``username``.
1081 1084
 
1082 1085
 QuerySets still return the model that was requested
1083 1086
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1084 1087
 
1085 1088
 There is no way to have Django return, say, a ``MyUser`` object whenever you
1086  
-query for ``User`` objects. A queryset for ``User`` objects will return those
1087  
-types of objects. The whole point of proxy objects is that code relying on the
1088  
-original ``User`` will use those and your own code can use the extensions you
1089  
-included (that no other code is relying on anyway). It is not a way to replace
1090  
-the ``User`` (or any other) model everywhere with something of your own
1091  
-creation.
  1089
+query for :class:`~django.contrib.auth.models.User` objects. A queryset for
  1090
+``User`` objects will return those types of objects. The whole point of proxy
  1091
+objects is that code relying on the original ``User`` will use those and your
  1092
+own code can use the extensions you included (that no other code is relying on
  1093
+anyway). It is not a way to replace the ``User`` (or any other) model
  1094
+everywhere with something of your own creation.
1092 1095
 
1093 1096
 Base class restrictions
1094 1097
 ~~~~~~~~~~~~~~~~~~~~~~~
@@ -1227,5 +1230,5 @@ column name, you can have the same column name appearing in both a child and
1227 1230
 an ancestor model for multi-table inheritance (they are columns in two
1228 1231
 different database tables).
1229 1232
 
1230  
-Django will raise a ``FieldError`` exception if you override any model field
1231  
-in any ancestor model.
  1233
+Django will raise a :exc:`~django.core.exceptions.FieldError` if you override
  1234
+any model field in any ancestor model.

0 notes on commit ffa4bad

Please sign in to comment.
Something went wrong with that request. Please try again.