Fixed #14842 - Indent the model Meta options. Thanks adamv.

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

docs/ref/models/options.txt

@@ -3,8 +3,8 @@ Model ``Meta`` options
 ======================
 
 This document explains all the possible :ref:`metadata options
-<meta-options>` that you can give your model in its internal ``class
+<meta-options>` that you can give your model in its internal
-Meta``.
+``class Meta``.
 
 Available ``Meta`` options
 ==========================
@@ -16,16 +16,17 @@ Available ``Meta`` options
 
 .. attribute:: Options.abstract
 
-If ``True``, this model will be an :ref:`abstract base class <abstract-base-classes>`.
+    If ``abstract = True``, this model will be an
+    :ref:`abstract base class <abstract-base-classes>`.
 
 ``app_label``
 -------------
 
 .. attribute:: Options.app_label
 
-If a model exists outside of the standard :file:`models.py` (for instance, if
+    If a model exists outside of the standard :file:`models.py` (for instance,
-the app's models are in submodules of ``myapp.models``), the model must define
+    if the app's models are in submodules of ``myapp.models``), the model must
-which app it is part of::
+    define which app it is part of::
 
         app_label = 'myapp'
 
@@ -34,7 +35,7 @@ which app it is part of::
 
 .. attribute:: Options.db_table
 
-The name of the database table to use for the model::
+    The name of the database table to use for the model::
 
         db_table = 'music_album'
 
@@ -46,8 +47,8 @@ Table names
 To save you time, Django automatically derives the name of the database table
 from the name of your model class and the app that contains it. A model's
 database table name is constructed by joining the model's "app label" -- the
-name you used in ``manage.py startapp`` -- to the model's class name, with an
+name you used in :djadmin:`manage.py startapp <startapp>` -- to the model's
-underscore between them.
+class name, with an underscore between them.
 
 For example, if you have an app ``bookstore`` (as created by
 ``manage.py startapp bookstore``), a model defined as ``class Book`` will have
@@ -65,38 +66,38 @@ Django quotes column and table names behind the scenes.
 
 .. attribute:: Options.db_tablespace
 
-The name of the database tablespace to use for the model. If the backend doesn't
+    The name of the database tablespace to use for the model. If the backend
-support tablespaces, this option is ignored.
+    doesn't support tablespaces, this option is ignored.
 
 ``get_latest_by``
 -----------------
 
 .. attribute:: Options.get_latest_by
 
-The name of a :class:`DateField` or :class:`DateTimeField` in the model. This
+    The name of a :class:`DateField` or :class:`DateTimeField` in the model.
-specifies the default field to use in your model :class:`Manager`'s
+    This specifies the default field to use in your model :class:`Manager`'s
-:class:`~QuerySet.latest` method.
+    :class:`~QuerySet.latest` method.
 
-Example::
+    Example::
 
         get_latest_by = "order_date"
 
-See the docs for :meth:`~django.db.models.QuerySet.latest` for more.
+    See the docs for :meth:`~django.db.models.QuerySet.latest` for more.
 
 ``managed``
------------------------
+-----------
 
 .. attribute:: Options.managed
 
-Defaults to ``True``, meaning Django will create the appropriate database
+    Defaults to ``True``, meaning Django will create the appropriate database
-tables in :djadmin:`syncdb` and remove them as part of a :djadmin:`reset`
+    tables in :djadmin:`syncdb` and remove them as part of a :djadmin:`reset`
-management command. That is, Django *manages* the database tables' lifecycles.
+    management command. That is, Django *manages* the database tables' lifecycles.
 
-If ``False``, no database table creation or deletion operations will be
+    If ``False``, no database table creation or deletion operations will be
-performed for this model. This is useful if the model represents an existing
+    performed for this model. This is useful if the model represents an existing
-table or a database view that has been created by some other means. This is
+    table or a database view that has been created by some other means. This is
-the *only* difference when ``managed`` is ``False``. All other aspects of
+    the *only* difference when ``managed=False``. All other aspects of
-model handling are exactly the same as normal. This includes
+    model handling are exactly the same as normal. This includes
 
         1. Adding an automatic primary key field to the model if you don't declare
            it.  To avoid confusion for later code readers, it's recommended to
@@ -114,23 +115,23 @@ model handling are exactly the same as normal. This includes
            :attr:`ManyToManyField.through` attribute to make the relation use your
            custom model.
 
-For tests involving models with ``managed=False``, it's up to you to ensure
+    For tests involving models with ``managed=False``, it's up to you to ensure
-the correct tables are created as part of the test setup.
+    the correct tables are created as part of the test setup.
 
-If you're interested in changing the Python-level behavior of a model class,
+    If you're interested in changing the Python-level behavior of a model class,
-you *could* use ``managed=False`` and create a copy of an existing model.
+    you *could* use ``managed=False`` and create a copy of an existing model.
-However, there's a better approach for that situation: :ref:`proxy-models`.
+    However, there's a better approach for that situation: :ref:`proxy-models`.
 
 ``order_with_respect_to``
 -------------------------
 
 .. attribute:: Options.order_with_respect_to
 
-Marks this object as "orderable" with respect to the given field. This is almost
+    Marks this object as "orderable" with respect to the given field. This is almost
-always used with related objects to allow them to be ordered with respect to a
+    always used with related objects to allow them to be ordered with respect to a
-parent object. For example, if an ``Answer`` relates to a ``Question`` object,
+    parent object. For example, if an ``Answer`` relates to a ``Question`` object,
-and a question has more than one answer, and the order of answers matters, you'd
+    and a question has more than one answer, and the order of answers matters, you'd
-do this::
+    do this::
 
         class Answer(models.Model):
             question = models.ForeignKey(Question)
@@ -139,25 +140,25 @@ do this::
             class Meta:
                 order_with_respect_to = 'question'
 
-When ``order_with_respect_to`` is set, two additional methods are provided to
+    When ``order_with_respect_to`` is set, two additional methods are provided to
-retrieve and to set the order of the related objects: ``get_RELATED_order()``
+    retrieve and to set the order of the related objects: ``get_RELATED_order()``
-and ``set_RELATED_order()``, where ``RELATED`` is the lowercased model name. For
+    and ``set_RELATED_order()``, where ``RELATED`` is the lowercased model name. For
-example, assuming that a ``Question`` object has multiple related ``Answer``
+    example, assuming that a ``Question`` object has multiple related ``Answer``
-objects, the list returned contains the primary keys of the related ``Answer``
+    objects, the list returned contains the primary keys of the related ``Answer``
-objects::
+    objects::
 
         >>> question = Question.objects.get(id=1)
         >>> question.get_answer_order()
         [1, 2, 3]
 
-The order of a ``Question`` object's related ``Answer`` objects can be set by
+    The order of a ``Question`` object's related ``Answer`` objects can be set by
-passing in a list of ``Answer`` primary keys::
+    passing in a list of ``Answer`` primary keys::
 
         >>> question.set_answer_order([3, 1, 2])
 
-The related objects also get two methods, ``get_next_in_order()`` and
+    The related objects also get two methods, ``get_next_in_order()`` and
-``get_previous_in_order()``, which can be used to access those objects in their
+    ``get_previous_in_order()``, which can be used to access those objects in their
-proper order. Assuming the ``Answer`` objects are ordered by ``id``::
+    proper order. Assuming the ``Answer`` objects are ordered by ``id``::
 
         >>> answer = Answer.objects.get(id=2)
         >>> answer.get_next_in_order()
@@ -170,28 +171,28 @@ proper order. Assuming the ``Answer`` objects are ordered by ``id``::
 
 .. attribute:: Options.ordering
 
-The default ordering for the object, for use when obtaining lists of objects::
+    The default ordering for the object, for use when obtaining lists of objects::
 
         ordering = ['-order_date']
 
-This is a tuple or list of strings. Each string is a field name with an optional
+    This is a tuple or list of strings. Each string is a field name with an optional
-"-" prefix, which indicates descending order. Fields without a leading "-" will
+    "-" prefix, which indicates descending order. Fields without a leading "-" will
-be ordered ascending. Use the string "?" to order randomly.
+    be ordered ascending. Use the string "?" to order randomly.
 
-.. note::
+    .. note::
 
         Regardless of how many fields are in :attr:`~Options.ordering`, the admin
         site uses only the first field.
 
-For example, to order by a ``pub_date`` field ascending, use this::
+    For example, to order by a ``pub_date`` field ascending, use this::
 
         ordering = ['pub_date']
 
-To order by ``pub_date`` descending, use this::
+    To order by ``pub_date`` descending, use this::
 
         ordering = ['-pub_date']
 
-To order by ``pub_date`` descending, then by ``author`` ascending, use this::
+    To order by ``pub_date`` descending, then by ``author`` ascending, use this::
 
         ordering = ['-pub_date', 'author']
 
@@ -200,40 +201,40 @@ To order by ``pub_date`` descending, then by ``author`` ascending, use this::
 
 .. attribute:: Options.permissions
 
-Extra permissions to enter into the permissions table when creating this object.
+    Extra permissions to enter into the permissions table when creating this object.
-Add, delete and change permissions are automatically created for each object
+    Add, delete and change permissions are automatically created for each object
-that has ``admin`` set. This example specifies an extra permission,
+    that has ``admin`` set. This example specifies an extra permission,
-``can_deliver_pizzas``::
+    ``can_deliver_pizzas``::
 
         permissions = (("can_deliver_pizzas", "Can deliver pizzas"),)
 
-This is a list or tuple of 2-tuples in the format ``(permission_code,
+    This is a list or tuple of 2-tuples in the format ``(permission_code,
-human_readable_permission_name)``.
+    human_readable_permission_name)``.
 
 ``proxy``
 ---------
 
 .. attribute:: Options.proxy
 
-If set to ``True``, a model which subclasses another model will be treated as
+    If ``proxy = True``, a model which subclasses another model will be treated as
-a :ref:`proxy model <proxy-models>`.
+    a :ref:`proxy model <proxy-models>`.
 
 ``unique_together``
 -------------------
 
 .. attribute:: Options.unique_together
 
-Sets of field names that, taken together, must be unique::
+    Sets of field names that, taken together, must be unique::
 
         unique_together = (("driver", "restaurant"),)
 
-This is a list of lists of fields that must be unique when considered together.
+    This is a list of lists of fields that must be unique when considered together.
-It's used in the Django admin and is enforced at the database level (i.e., the
+    It's used in the Django admin and is enforced at the database level (i.e., the
-appropriate ``UNIQUE`` statements are included in the ``CREATE TABLE``
+    appropriate ``UNIQUE`` statements are included in the ``CREATE TABLE``
-statement).
+    statement).
 
-For convenience, unique_together can be a single list when dealing with a single
+    For convenience, unique_together can be a single list when dealing with a single
-set of fields::
+    set of fields::
 
         unique_together = ("driver", "restaurant")
 
@@ -242,20 +243,20 @@ set of fields::
 
 .. attribute:: Options.verbose_name
 
-A human-readable name for the object, singular::
+    A human-readable name for the object, singular::
 
         verbose_name = "pizza"
 
-If this isn't given, Django will use a munged version of the class name:
+    If this isn't given, Django will use a munged version of the class name:
-``CamelCase`` becomes ``camel case``.
+    ``CamelCase`` becomes ``camel case``.
 
 ``verbose_name_plural``
 -----------------------
 
 .. attribute:: Options.verbose_name_plural
 
-The plural name for the object::
+    The plural name for the object::
 
         verbose_name_plural = "stories"
 
-If this isn't given, Django will use :attr:`~Options.verbose_name` + ``"s"``.
+    If this isn't given, Django will use :attr:`~Options.verbose_name` + ``"s"``.