Fixed #14141: docs now use the :doc: construct for links between documents.

Thanks, Ramiro Morales.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@13608 bcc190cf-cafb-0310-a4f2-bffc1f526a37

docs/topics/db/aggregation.txt

@@ -1,5 +1,3 @@
-.. _topics-db-aggregation:
-
 ===========
 Aggregation
 ===========
@@ -8,7 +6,7 @@ Aggregation
 
 .. currentmodule:: django.db.models
 
-The topic guide on :ref:`Django's database-abstraction API <topics-db-queries>`
+The topic guide on :doc:`Django's database-abstraction API </topics/db/queries>`
 described the way that you can use Django queries that create,
 retrieve, update and delete individual objects. However, sometimes you will
 need to retrieve values that are derived by summarizing or *aggregating* a
@@ -363,7 +361,7 @@ you also select in a ``values()`` call.
     for you. The main reason is consistency with ``distinct()`` and other
     places: Django **never** removes ordering constraints that you have
     specified (and we can't change those other methods' behavior, as that
-    would violate our :ref:`misc-api-stability` policy).
+    would violate our :doc:`/misc/api-stability` policy).
 
 Aggregating annotations
 -----------------------

docs/topics/db/index.txt

@@ -1,5 +1,3 @@
-.. _topics-db-index:
-
 Models and databases
 ====================
 

docs/topics/db/managers.txt

@@ -1,5 +1,3 @@
-.. _topics-db-managers:
-
 ========
 Managers
 ========
@@ -12,7 +10,7 @@ A ``Manager`` is the interface through which database query operations are
 provided to Django models. At least one ``Manager`` exists for every model in
 a Django application.
 
-The way ``Manager`` classes work is documented in :ref:`topics-db-queries`;
+The way ``Manager`` classes work is documented in :doc:`/topics/db/queries`;
 this document specifically touches on model options that customize ``Manager``
 behavior.
 
@@ -325,7 +323,7 @@ it will use :class:`django.db.models.Manager`.
     attribute only controlled the type of manager used for related field
     access, which is where the name came from. As it became clear the concept
     was more broadly useful, the name hasn't been changed. This is primarily
-    so that existing code will :ref:`continue to work <misc-api-stability>` in
+    so that existing code will :doc:`continue to work </misc/api-stability>` in
     future Django versions.
 
 Writing Correct Managers For Use In Automatic Manager Instances

docs/topics/db/models.txt

@@ -1,5 +1,3 @@
-.. _topics-db-models:
-
 ======
 Models
 ======
@@ -18,7 +16,7 @@ The basics:
     * Each attribute of the model represents a database field.
 
     * With all of this, Django gives you an automatically-generated
-      database-access API; see :ref:`topics-db-queries`.
+      database-access API; see :doc:`/topics/db/queries`.
 
 .. seealso::
 
@@ -64,7 +62,7 @@ Some technical notes:
 
     * The ``CREATE TABLE`` SQL in this example is formatted using PostgreSQL
       syntax, but it's worth noting Django uses SQL tailored to the database
-      backend specified in your :ref:`settings file <topics-settings>`.
+      backend specified in your :doc:`settings file </topics/settings>`.
 
 Using models
 ============
@@ -126,7 +124,7 @@ determine a few things:
 Django ships with dozens of built-in field types; you can find the complete list
 in the :ref:`model field reference <model-field-types>`. You can easily write
 your own fields if Django's built-in ones don't do the trick; see
-:ref:`howto-custom-model-fields`.
+:doc:`/howto/custom-model-fields`.
 
 Field options
 -------------
@@ -612,7 +610,7 @@ Custom field types
 If one of the existing model fields cannot be used to fit your purposes, or if
 you wish to take advantage of some less common database column types, you can
 create your own field class. Full coverage of creating your own fields is
-provided in :ref:`howto-custom-model-fields`.
+provided in :doc:`/howto/custom-model-fields`.
 
 .. _meta-options:
 
@@ -634,8 +632,8 @@ human-readable singular and plural names (:attr:`~Options.verbose_name` and
 :attr:`~Options.verbose_name_plural`). None are required, and adding ``class
 Meta`` to a model is completely optional.
 
-A complete list of all possible ``Meta`` options can be found in the :ref:`model
-option reference <ref-models-options>`.
+A complete list of all possible ``Meta`` options can be found in the :doc:`model
+option reference </ref/models/options>`.
 
 .. _model-methods:
 
@@ -684,7 +682,7 @@ properties`_.
 
 .. _Read more about properties: http://www.python.org/download/releases/2.2/descrintro/#property
 
-The :ref:`model instance reference <ref-models-instances>` has a complete list
+The :doc:`model instance reference </ref/models/instances>` has a complete list
 of :ref:`methods automatically given to each model <model-instance-methods>`.
 You can override most of these -- see `overriding predefined model methods`_,
 below -- but there are a couple that you'll almost always want to define:
@@ -763,7 +761,7 @@ Executing custom SQL
 
 Another common pattern is writing custom SQL statements in model methods and
 module-level methods. For more details on using raw SQL, see the documentation
-on :ref:`using raw SQL<topics-db-sql>`.
+on :doc:`using raw SQL</topics/db/sql>`.
 
 .. _model-inheritance:
 

docs/topics/db/multi-db.txt

@@ -1,5 +1,3 @@
-.. _topics-db-multi-db:
-
 ==================
 Multiple databases
 ==================

docs/topics/db/optimization.txt

@@ -1,5 +1,3 @@
-.. _topics-db-optimization:
-
 ============================
 Database access optimization
 ============================
@@ -45,13 +43,13 @@ Use standard DB optimization techniques
 We will assume you have done the obvious things above. The rest of this document
 focuses on how to use Django in such a way that you are not doing unnecessary
 work. This document also does not address other optimization techniques that
-apply to all expensive operations, such as :ref:`general purpose caching
-<topics-cache>`.
+apply to all expensive operations, such as :doc:`general purpose caching
+</topics/cache>`.
 
 Understand QuerySets
 ====================
 
-Understanding :ref:`QuerySets <ref-models-querysets>` is vital to getting good
+Understanding :doc:`QuerySets </ref/models/querysets>` is vital to getting good
 performance with simple code. In particular:
 
 Understand QuerySet evaluation
@@ -114,7 +112,7 @@ For instance:
 * Use :ref:`F() object query expressions <query-expressions>` to do filtering
   against other fields within the same model.
 
-* Use :ref:`annotate to do aggregation in the database <topics-db-aggregation>`.
+* Use :doc:`annotate to do aggregation in the database </topics/db/aggregation>`.
 
 If these aren't enough to generate the SQL you need:
 
@@ -128,8 +126,8 @@ explicitly added to the query. If that still isn't powerful enough:
 Use raw SQL
 -----------
 
-Write your own :ref:`custom SQL to retrieve data or populate models
-<topics-db-sql>`. Use ``django.db.connection.queries`` to find out what Django
+Write your own :doc:`custom SQL to retrieve data or populate models
+</topics/db/sql>`. Use ``django.db.connection.queries`` to find out what Django
 is writing for you and start from there.
 
 Retrieve everything at once if you know you will need it
@@ -148,7 +146,7 @@ Understand :ref:`QuerySet.select_related() <select-related>` thoroughly, and use
 
 * in view code,
 
-* and in :ref:`managers and default managers <topics-db-managers>` where
+* and in :doc:`managers and default managers </topics/db/managers>` where
   appropriate. Be aware when your manager is and is not used; sometimes this is
   tricky so don't make assumptions.
 
@@ -243,7 +241,7 @@ individual, use a bulk SQL UPDATE statement, via :ref:`QuerySet.update()
 Note, however, that these bulk update methods cannot call the ``save()`` or ``delete()``
 methods of individual instances, which means that any custom behaviour you have
 added for these methods will not be executed, including anything driven from the
-normal database object :ref:`signals <ref-signals>`.
+normal database object :doc:`signals </ref/signals>`.
 
 Use foreign key values directly
 -------------------------------

docs/topics/db/queries.txt

@@ -1,15 +1,13 @@
-.. _topics-db-queries:
-
 ==============
 Making queries
 ==============
 
 .. currentmodule:: django.db.models
 
-Once you've created your :ref:`data models <topics-db-models>`, Django
+Once you've created your :doc:`data models </topics/db/models>`, Django
 automatically gives you a database-abstraction API that lets you create,
 retrieve, update and delete objects. This document explains how to use this
-API. Refer to the :ref:`data model reference <ref-models-index>` for full
+API. Refer to the :doc:`data model reference </ref/models/index>` for full
 details of all the various model lookup options.
 
 Throughout this guide (and in the reference), we'll refer to the following
@@ -937,7 +935,7 @@ be accessed from an instance::
 In addition to the ``QuerySet`` methods defined in "Retrieving objects" above,
 the ``ForeignKey`` ``Manager`` has additional methods used to handle the set of
 related objects. A synopsis of each is below, and complete details can be found
-in the :ref:`related objects reference <ref-models-relations>`.
+in the :doc:`related objects reference </ref/models/relations>`.
 
 ``add(obj1, obj2, ...)``
     Adds the specified model objects to the related object set.
@@ -1067,7 +1065,7 @@ Falling back to raw SQL
 If you find yourself needing to write an SQL query that is too complex for
 Django's database-mapper to handle, you can fall back on writing SQL by hand.
 Django has a couple of options for writing raw SQL queries; see
-:ref:`topics-db-sql`.
+:doc:`/topics/db/sql`.
 
 Finally, it's important to note that the Django database layer is merely an
 interface to your database. You can access your database via other tools,

docs/topics/db/sql.txt

@@ -1,12 +1,10 @@
-.. _topics-db-sql:
-
 ==========================
 Performing raw SQL queries
 ==========================
 
 .. currentmodule:: django.db.models
 
-When the :ref:`model query APIs <topics-db-queries>` don't go far enough, you
+When the :doc:`model query APIs </topics/db/queries>` don't go far enough, you
 can fall back to writing raw SQL. Django gives you two ways of performing raw
 SQL queries: you can use :meth:`Manager.raw()` to `perform raw queries and
 return model instances`__, or you can avoid the model layer entirely and
@@ -269,7 +267,7 @@ Connections and cursors
 -----------------------
 
 ``connection`` and ``cursor`` mostly implement the standard `Python DB-API`_
-(except when it comes to :ref:`transaction handling <topics-db-transactions>`).
+(except when it comes to :doc:`transaction handling </topics/db/transactions>`).
 If you're not familiar with the Python DB-API, note that the SQL statement in
 ``cursor.execute()`` uses placeholders, ``"%s"``, rather than adding parameters
 directly within the SQL. If you use this technique, the underlying database

docs/topics/db/transactions.txt

@@ -1,5 +1,3 @@
-.. _topics-db-transactions:
-
 ==============================
 Managing database transactions
 ==============================
@@ -306,7 +304,7 @@ Database-level autocommit
 .. versionadded:: 1.1
 
 With PostgreSQL 8.2 or later, there is an advanced option to run PostgreSQL
-with :ref:`database-level autocommit <ref-databases>`. If you use this option,
+with :doc:`database-level autocommit </ref/databases>`. If you use this option,
 there is no constantly open transaction, so it is always possible to continue
 after catching an exception. For example::