[1.9.x] Unified some doc links to OneToOneField and ManyToManyField.

Backport of 8ce8beb3f24042ed0c3da00ef3d23c25036021ed from master

6 files changed, 14 insertions, 20 deletions

diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index fa8eb51ddf..6024078e35 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -1387,8 +1387,6 @@ The possible values for :attr:`~ForeignKey.on_delete` are found in
 
     If in doubt, leave it to its default of ``True``.
 
-.. _ref-manytomany:
-
 ``ManyToManyField``
 -------------------
 
@@ -1592,8 +1590,6 @@ that control how the relationship functions.
 :attr:`~Field.null` has no effect since there is no way to require a
 relationship at the database level.
 
-.. _ref-onetoone:
-
 ``OneToOneField``
 -----------------
 
diff --git a/docs/releases/1.7.txt b/docs/releases/1.7.txt
index 875c5792fa..2dad0d1b00 100644
--- a/docs/releases/1.7.txt
+++ b/docs/releases/1.7.txt
@@ -76,8 +76,8 @@ but a few of the key features are:
   <test-case-serialized-rollback>`.
 
 * It is not advised to have apps without migrations depend on (have a
-  :ref:`ForeignKey <ref-foreignkey>` or :ref:`ManyToManyField <ref-manytomany>`
-  to) apps with migrations.
+  :class:`~django.db.models.ForeignKey` or
+  :class:`~django.db.models.ManyToManyField` to) apps with migrations.
 
 * If you are upgrading from South, see our :ref:`upgrading-from-south`
   documentation, and third-party app authors should read the
diff --git a/docs/topics/auth/customizing.txt b/docs/topics/auth/customizing.txt
index cf790fbc49..4744266a47 100644
--- a/docs/topics/auth/customizing.txt
+++ b/docs/topics/auth/customizing.txt
@@ -303,8 +303,8 @@ change to what is stored in the database, you can create a :ref:`proxy model
 allows for any of the features offered by proxy models including default
 ordering, custom managers, or custom model methods.
 
-If you wish to store information related to ``User``, you can use a :ref:`one-to-one
-relationship <ref-onetoone>` to a model containing the fields for
+If you wish to store information related to ``User``, you can use a
+:class:`~django.db.models.OneToOneField` to a model containing the fields for
 additional information. This one-to-one model is often called a profile model,
 as it might store non-auth related information about a site user. For example
 you might create an Employee model::
diff --git a/docs/topics/db/examples/many_to_many.txt b/docs/topics/db/examples/many_to_many.txt
index 4fcd36cbd6..b9b1b4a2ce 100644
--- a/docs/topics/db/examples/many_to_many.txt
+++ b/docs/topics/db/examples/many_to_many.txt
@@ -4,7 +4,8 @@ Many-to-many relationships
 
 .. highlight:: pycon
 
-To define a many-to-many relationship, use :ref:`ref-manytomany`.
+To define a many-to-many relationship, use
+:class:`~django.db.models.ManyToManyField`.
 
 In this example, an ``Article`` can be published in multiple ``Publication``
 objects, and a ``Publication`` has multiple ``Article`` objects:
diff --git a/docs/topics/db/examples/one_to_one.txt b/docs/topics/db/examples/one_to_one.txt
index 8d7fb7de26..43bb2fcc62 100644
--- a/docs/topics/db/examples/one_to_one.txt
+++ b/docs/topics/db/examples/one_to_one.txt
@@ -2,7 +2,8 @@
 One-to-one relationships
 ========================
 
-To define a one-to-one relationship, use :ref:`ref-onetoone`.
+To define a one-to-one relationship, use
+:class:`~django.db.models.OneToOneField`.
 
 In this example, a ``Place`` optionally can be a ``Restaurant``::
 
diff --git a/docs/topics/db/models.txt b/docs/topics/db/models.txt
index 5ebea94923..16815bccae 100644
--- a/docs/topics/db/models.txt
+++ b/docs/topics/db/models.txt
@@ -387,8 +387,7 @@ For example, if a ``Pizza`` has multiple ``Topping`` objects -- that is, a
 As with :class:`~django.db.models.ForeignKey`, you can also create
 :ref:`recursive relationships <recursive-relationships>` (an object with a
 many-to-many relationship to itself) and :ref:`relationships to models not yet
-defined <lazy-relationships>`; see :ref:`the model field reference
-<ref-manytomany>` for details.
+defined <lazy-relationships>`.
 
 It's suggested, but not required, that the name of a
 :class:`~django.db.models.ManyToManyField` (``toppings`` in the example above)
@@ -599,20 +598,17 @@ restaurant "is a" place; in fact, to handle this you'd typically use
 :ref:`inheritance <model-inheritance>`, which involves an implicit
 one-to-one relation).
 
-As with :class:`~django.db.models.ForeignKey`, a
-:ref:`recursive relationship <recursive-relationships>`
-can be defined and
-:ref:`references to as-yet undefined models <lazy-relationships>`
-can be made; see :ref:`the model field reference <ref-onetoone>` for details.
+As with :class:`~django.db.models.ForeignKey`, a :ref:`recursive relationship
+<recursive-relationships>` can be defined and :ref:`references to as-yet
+undefined models <lazy-relationships>` can be made.
 
 .. seealso::
 
     See the :doc:`One-to-one relationship model example
     </topics/db/examples/one_to_one>` for a full example.
 
-:class:`~django.db.models.OneToOneField` fields also accept one specific,
-optional ``parent_link`` argument described in the :ref:`model field
-reference <ref-onetoone>`.
+:class:`~django.db.models.OneToOneField` fields also accept an optional
+:attr:`~django.db.models.OneToOneField.parent_link` argument.
 
 :class:`~django.db.models.OneToOneField` classes used to automatically become
 the primary key on a model. This is no longer true (although you can manually