test0908
/
django
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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:
Jacob Kaplan-Moss 2008-08-25 15:51:13 +00:00
parent 964769871d
commit 97bc872755
1 changed files with 32 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
docs/topics/db/models.txt
View File

@ -40,7 +40,7 @@ This example model defines a ``Person``, which has a ``first_name`` and
first_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
column.
@ -147,7 +147,7 @@ ones:
If ``True``, Django will store empty values as ``NULL`` in the database.
Default is ``False``.
:attr:`~ieldblank`
:attr:`~Field.blank`
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
admin form.
:attr:`~Field.primary_key``
:attr:`~Field.primary_key`
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
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
~~~~~~~~~~~~~~~~~~~~~~~~~
@ -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
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
reference <ref-foreignkey>` for details.`
reference <ref-foreignkey>` for details.
It's suggested, but not required, that the name of a
: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.
.. _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
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
many-to-one relationship to itself) and :ref:`relationships to models not yet
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
: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.
.. _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
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**
When you're only dealing with simple many-to-many relationships such as
mixing and matching pizzas and toppings, a standard ``ManyToManyField``
is all you need. However, sometimes you may need to associate data with the
relationship between two models.
mixing and matching pizzas and toppings, a standard :class:`~django.db.models.ManyToManyField` is all you need. However, sometimes
you may need to associate data with the relationship between two models.
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
and the groups of which they are a member, so you could use a ManyToManyField
to represent this relationship. However, there is a lot of detail about the
membership that you might want to collect, such as the date at which the person
joined the group.
and the groups of which they are a member, so you could use a
:class:`~django.db.models.ManyToManyField` to represent this relationship.
However, there is a lot of detail about the membership that you might want to
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
to govern the many-to-many relationship. You can then put extra fields on 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
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
itself, using an intermediary model, you *must* use
``symmetrical=False`` (see the documentation for
``ManyToManyField`` above).
:attr:`symmetrical=False <ManyToManyFields.symmetrical>` (see
:ref:`the model field reference <manytomany-arguments>`).
Now that you have set up your ``ManyToManyField`` to use your intermediary
model (Membership, in this case), you're ready to start creating some
many-to-many relationships. You do this by creating instances of the
intermediate model::
Now that you have set up your :class:`~django.db.models.ManyToManyField` to use
your intermediary model (Membership, in this case), you're ready to start
creating some many-to-many relationships. You do this by creating instances of
the intermediate model::
>>> ringo = Person.objects.create(name="Ringo Starr")
>>> 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
define a ``OneToOneField`` on your model, instances of that model will have
access to the related object via a simple attribute of the model.
define a :class:`~django.db.models.OneToOneField` on your model, instances of
that model will have access to the related object via a simple attribute of the
model.
For example::
@ -515,8 +516,9 @@ For example::
ed.entry # Returns the related Entry object.
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``
represents a single object, rather than a collection of objects::
relationship also has access to a :class:`~django.db.models.Manager` object, but
that :class:`~django.db.models.Manager` represents a single object, rather than
a collection of objects::
e = Entry.objects.get(id=2)
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
The :ref:`model instance reference <ref-models-instances>` has a complete list
of `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:
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:
:meth:`~Model.__unicode__`
A Python "magic method" that returns a unicode "representation" of any