Unified some doc links to OneToOneField and ManyToManyField.

docs/ref/models/fields.txt

@@ -1386,8 +1386,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``
 -------------------
 
@@ -1591,8 +1589,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``
 -----------------
 

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.
 
 .. _app-loading-refactor-17-release-note:
 

docs/topics/auth/customizing.txt

@@ -300,8 +300,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::

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:

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``::
 

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)
@@ -610,20 +609,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