Fixed a handful of typo/markup problems in the docs. Patch from Daniel Roseman.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8540 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
964769871d
commit
97bc872755
|
@ -40,7 +40,7 @@ This example model defines a ``Person``, which has a ``first_name`` and
|
||||||
first_name = models.CharField(max_length=30)
|
first_name = models.CharField(max_length=30)
|
||||||
last_name = models.CharField(max_length=30)
|
last_name = models.CharField(max_length=30)
|
||||||
|
|
||||||
``first_name`` and ``last_name`` are :term:`fields <field>` of the model. Each
|
``first_name`` and ``last_name`` are :ref:`fields` of the model. Each
|
||||||
field is specified as a class attribute, and each attribute maps to a database
|
field is specified as a class attribute, and each attribute maps to a database
|
||||||
column.
|
column.
|
||||||
|
|
||||||
|
@ -147,7 +147,7 @@ ones:
|
||||||
If ``True``, Django will store empty values as ``NULL`` in the database.
|
If ``True``, Django will store empty values as ``NULL`` in the database.
|
||||||
Default is ``False``.
|
Default is ``False``.
|
||||||
|
|
||||||
:attr:`~ieldblank`
|
:attr:`~Field.blank`
|
||||||
|
|
||||||
If ``True``, the field is allowed to be blank. Default is ``False``.
|
If ``True``, the field is allowed to be blank. Default is ``False``.
|
||||||
|
|
||||||
|
@ -187,7 +187,7 @@ ones:
|
||||||
form. It's useful for documentation even if your object doesn't have an
|
form. It's useful for documentation even if your object doesn't have an
|
||||||
admin form.
|
admin form.
|
||||||
|
|
||||||
:attr:`~Field.primary_key``
|
:attr:`~Field.primary_key`
|
||||||
|
|
||||||
If ``True``, this field is the primary key for the model.
|
If ``True``, this field is the primary key for the model.
|
||||||
|
|
||||||
|
@ -261,7 +261,7 @@ Relationships
|
||||||
|
|
||||||
Clearly, the power of relational databases lies in relating tables to each
|
Clearly, the power of relational databases lies in relating tables to each
|
||||||
other. Django offers ways to define the three most common types of database
|
other. Django offers ways to define the three most common types of database
|
||||||
relationships: Many-to-one, many-to-many and one-to-one.
|
relationships: many-to-one, many-to-many and one-to-one.
|
||||||
|
|
||||||
Many-to-one relationships
|
Many-to-one relationships
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
@ -285,9 +285,9 @@ For example, if a ``Car`` model has a ``Manufacturer`` -- that is, a
|
||||||
# ...
|
# ...
|
||||||
|
|
||||||
You can also create :ref:`recursive relationships <recursive-relationships>` (an
|
You can also create :ref:`recursive relationships <recursive-relationships>` (an
|
||||||
object with a many-to-one relationship to itself) and :ref:`relationsips to
|
object with a many-to-one relationship to itself) and :ref:`relationships to
|
||||||
models not yet defined <lazy-relationships>`; see :ref:`the model field
|
models not yet defined <lazy-relationships>`; see :ref:`the model field
|
||||||
reference <ref-foreignkey>` for details.`
|
reference <ref-foreignkey>` for details.
|
||||||
|
|
||||||
It's suggested, but not required, that the name of a
|
It's suggested, but not required, that the name of a
|
||||||
:class:`~django.db.models.ForeignKey` field (``manufacturer`` in the example
|
:class:`~django.db.models.ForeignKey` field (``manufacturer`` in the example
|
||||||
|
@ -302,7 +302,7 @@ whatever you want. For example::
|
||||||
|
|
||||||
See the `Many-to-one relationship model example`_ for a full example.
|
See the `Many-to-one relationship model example`_ for a full example.
|
||||||
|
|
||||||
.. _Many-to-one relationship model example: http://www.djangoproject.com/models/many_to_one/
|
.. _Many-to-one relationship model example: http://www.djangoproject.com/documentation/models/many_to_one/
|
||||||
|
|
||||||
:class:`~django.db.models.ForeignKey` fields also accept a number of extra
|
:class:`~django.db.models.ForeignKey` fields also accept a number of extra
|
||||||
arguments which are explained in :ref:`the model field reference
|
arguments which are explained in :ref:`the model field reference
|
||||||
|
@ -335,7 +335,7 @@ As with :class:`~django.db.models.ForeignKey`, you can also create
|
||||||
:ref:`recursive relationships <recursive-relationships>` (an object with a
|
:ref:`recursive relationships <recursive-relationships>` (an object with a
|
||||||
many-to-one relationship to itself) and :ref:`relationships to models not yet
|
many-to-one relationship to itself) and :ref:`relationships to models not yet
|
||||||
defined <lazy-relationships>`; see :ref:`the model field reference
|
defined <lazy-relationships>`; see :ref:`the model field reference
|
||||||
<ref-manytomany>` for details.`
|
<ref-manytomany>` for details.
|
||||||
|
|
||||||
It's suggested, but not required, that the name of a
|
It's suggested, but not required, that the name of a
|
||||||
:class:`~django.db.models.ManyToManyField` (``toppings`` in the example above)
|
:class:`~django.db.models.ManyToManyField` (``toppings`` in the example above)
|
||||||
|
@ -357,7 +357,7 @@ form would let users select the toppings.
|
||||||
|
|
||||||
See the `Many-to-many relationship model example`_ for a full example.
|
See the `Many-to-many relationship model example`_ for a full example.
|
||||||
|
|
||||||
.. _Many-to-many relationship model example: http://www.djangoproject.com/models/many_to_many/
|
.. _Many-to-many relationship model example: http://www.djangoproject.com/documentation/models/many_to_many/
|
||||||
|
|
||||||
:class:`~django.db.models.ManyToManyField` fields also accept a number of extra
|
:class:`~django.db.models.ManyToManyField` fields also accept a number of extra
|
||||||
arguments which are explained in :ref:`the model field reference
|
arguments which are explained in :ref:`the model field reference
|
||||||
|
@ -370,21 +370,21 @@ Extra fields on many-to-many relationships
|
||||||
**New in Django development version**
|
**New in Django development version**
|
||||||
|
|
||||||
When you're only dealing with simple many-to-many relationships such as
|
When you're only dealing with simple many-to-many relationships such as
|
||||||
mixing and matching pizzas and toppings, a standard ``ManyToManyField``
|
mixing and matching pizzas and toppings, a standard :class:`~django.db.models.ManyToManyField` is all you need. However, sometimes
|
||||||
is all you need. However, sometimes you may need to associate data with the
|
you may need to associate data with the relationship between two models.
|
||||||
relationship between two models.
|
|
||||||
|
|
||||||
For example, consider the case of an application tracking the musical groups
|
For example, consider the case of an application tracking the musical groups
|
||||||
which musicians belong to. There is a many-to-many relationship between a person
|
which musicians belong to. There is a many-to-many relationship between a person
|
||||||
and the groups of which they are a member, so you could use a ManyToManyField
|
and the groups of which they are a member, so you could use a
|
||||||
to represent this relationship. However, there is a lot of detail about the
|
:class:`~django.db.models.ManyToManyField` to represent this relationship.
|
||||||
membership that you might want to collect, such as the date at which the person
|
However, there is a lot of detail about the membership that you might want to
|
||||||
joined the group.
|
collect, such as the date at which the person joined the group.
|
||||||
|
|
||||||
For these situations, Django allows you to specify the model that will be used
|
For these situations, Django allows you to specify the model that will be used
|
||||||
to govern the many-to-many relationship. You can then put extra fields on the
|
to govern the many-to-many relationship. You can then put extra fields on the
|
||||||
intermediate model. The intermediate model is associated with the
|
intermediate model. The intermediate model is associated with the
|
||||||
``ManyToManyField`` using the ``through`` argument to point to the model
|
:class:`~django.db.models.ManyToManyField` using the
|
||||||
|
:attr:`through <ManyToManyFields.through>` argument to point to the model
|
||||||
that will act as an intermediary. For our musician example, the code would look
|
that will act as an intermediary. For our musician example, the code would look
|
||||||
something like this::
|
something like this::
|
||||||
|
|
||||||
|
@ -429,13 +429,13 @@ There are a few restrictions on the intermediate model:
|
||||||
|
|
||||||
* When defining a many-to-many relationship from a model to
|
* When defining a many-to-many relationship from a model to
|
||||||
itself, using an intermediary model, you *must* use
|
itself, using an intermediary model, you *must* use
|
||||||
``symmetrical=False`` (see the documentation for
|
:attr:`symmetrical=False <ManyToManyFields.symmetrical>` (see
|
||||||
``ManyToManyField`` above).
|
:ref:`the model field reference <manytomany-arguments>`).
|
||||||
|
|
||||||
Now that you have set up your ``ManyToManyField`` to use your intermediary
|
Now that you have set up your :class:`~django.db.models.ManyToManyField` to use
|
||||||
model (Membership, in this case), you're ready to start creating some
|
your intermediary model (Membership, in this case), you're ready to start
|
||||||
many-to-many relationships. You do this by creating instances of the
|
creating some many-to-many relationships. You do this by creating instances of
|
||||||
intermediate model::
|
the intermediate model::
|
||||||
|
|
||||||
>>> ringo = Person.objects.create(name="Ringo Starr")
|
>>> ringo = Person.objects.create(name="Ringo Starr")
|
||||||
>>> paul = Person.objects.create(name="Paul McCartney")
|
>>> paul = Person.objects.create(name="Paul McCartney")
|
||||||
|
@ -502,8 +502,9 @@ One-to-one relationships
|
||||||
------------------------
|
------------------------
|
||||||
|
|
||||||
One-to-one relationships are very similar to many-to-one relationships. If you
|
One-to-one relationships are very similar to many-to-one relationships. If you
|
||||||
define a ``OneToOneField`` on your model, instances of that model will have
|
define a :class:`~django.db.models.OneToOneField` on your model, instances of
|
||||||
access to the related object via a simple attribute of the model.
|
that model will have access to the related object via a simple attribute of the
|
||||||
|
model.
|
||||||
|
|
||||||
For example::
|
For example::
|
||||||
|
|
||||||
|
@ -515,8 +516,9 @@ For example::
|
||||||
ed.entry # Returns the related Entry object.
|
ed.entry # Returns the related Entry object.
|
||||||
|
|
||||||
The difference comes in "reverse" queries. The related model in a one-to-one
|
The difference comes in "reverse" queries. The related model in a one-to-one
|
||||||
relationship also has access to a ``Manager`` object, but that ``Manager``
|
relationship also has access to a :class:`~django.db.models.Manager` object, but
|
||||||
represents a single object, rather than a collection of objects::
|
that :class:`~django.db.models.Manager` represents a single object, rather than
|
||||||
|
a collection of objects::
|
||||||
|
|
||||||
e = Entry.objects.get(id=2)
|
e = Entry.objects.get(id=2)
|
||||||
e.entrydetail # returns the related EntryDetail object
|
e.entrydetail # returns the related EntryDetail object
|
||||||
|
@ -647,9 +649,9 @@ properties`_.
|
||||||
.. _Read more about properties: http://www.python.org/download/releases/2.2/descrintro/#property
|
.. _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 :ref:`model instance reference <ref-models-instances>` has a complete list
|
||||||
of `methods automatically given to each model <model-instance-methods>`. You can
|
of :ref:`methods automatically given to each model <model-instance-methods>`.
|
||||||
override most of these -- see `overriding predefined model methods`_, below --
|
You can override most of these -- see `overriding predefined model methods`_,
|
||||||
but there are a couple that you'll almost always want to define:
|
below -- but there are a couple that you'll almost always want to define:
|
||||||
|
|
||||||
:meth:`~Model.__unicode__`
|
:meth:`~Model.__unicode__`
|
||||||
A Python "magic method" that returns a unicode "representation" of any
|
A Python "magic method" that returns a unicode "representation" of any
|
||||||
|
|
Loading…
Reference in New Issue