Made a bunch of spelling corrections.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@7480 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Malcolm Tredinnick 2008-04-27 11:55:47 +00:00
parent d0c49e7b77
commit f0bc9426b4
2 changed files with 8 additions and 8 deletions

View File

@ -392,7 +392,7 @@ This returns the sixth through tenth objects (``OFFSET 5 LIMIT 5``)::
Entry.objects.all()[5:10] Entry.objects.all()[5:10]
You can also slice from the item ''N'' to the end of the queryset. For You can also slice from the item ''N'' to the end of the queryset. For
example, to return everything from the fixth item onwards:: example, to return everything from the sixth item onwards::
Entry.objects.all()[5:] Entry.objects.all()[5:]
@ -570,7 +570,7 @@ query spans multiple tables, it's possible to get duplicate results when a
.. note:: .. note::
Any fields used in an ``order_by()`` call are included in the SQL Any fields used in an ``order_by()`` call are included in the SQL
``SELECT`` columns. This can sometimes lead to unexpected results when ``SELECT`` columns. This can sometimes lead to unexpected results when
used in conjuntion with ``distinct()``. If you order by fields from a used in conjunction with ``distinct()``. If you order by fields from a
related model, those fields will be added to the selected columns and they related model, those fields will be added to the selected columns and they
may make otherwise duplicate rows appear to be distinct. Since the extra may make otherwise duplicate rows appear to be distinct. Since the extra
columns don't appear in the returned results (they are only there to columns don't appear in the returned results (they are only there to
@ -683,7 +683,7 @@ dictionaries, it returns a list of tuples. Each tuple contains the value from
the respective field passed into the ``values_list()`` call -- so the first the respective field passed into the ``values_list()`` call -- so the first
item is the first field, etc. For example:: item is the first field, etc. For example::
>>> Entry.objects.values_list('id', 'headling') >>> Entry.objects.values_list('id', 'headline')
[(1, u'First entry'), ...] [(1, u'First entry'), ...]
If you only pass in a single field, you can also pass in the ``flat`` If you only pass in a single field, you can also pass in the ``flat``
@ -837,7 +837,7 @@ models. In these cases, you can pass the related field names to
``select_related()`` and it will only follow those relations. You can even do ``select_related()`` and it will only follow those relations. You can even do
this for models that are more than one relation away by separating the field this for models that are more than one relation away by separating the field
names with double underscores, just as for filters. For example, if we have names with double underscores, just as for filters. For example, if we have
thise model:: this model::
class Room(models.Model): class Room(models.Model):
# ... # ...
@ -2103,7 +2103,7 @@ Updating multiple objects at once
Sometimes you want to set a field to a particular value for all the objects in Sometimes you want to set a field to a particular value for all the objects in
a queryset. You can do this with the ``update()`` method. For example:: a queryset. You can do this with the ``update()`` method. For example::
# Update all the headlings to the same value. # Update all the headlines to the same value.
Entry.objects.all().update(headline='Everything is the same') Entry.objects.all().update(headline='Everything is the same')
You can only set non-relation fields and ``ForeignKey`` fields using this You can only set non-relation fields and ``ForeignKey`` fields using this

View File

@ -52,7 +52,7 @@ Some technical notes:
* The name of the table, ``myapp_person``, is automatically derived from * The name of the table, ``myapp_person``, is automatically derived from
some model metadata but can be overridden. See `Table names`_ below. some model metadata but can be overridden. See `Table names`_ below.
* An ``id`` field is added automatically, but this behavior can be * An ``id`` field is added automatically, but this behavior can be
overriden. See `Automatic primary key fields`_ below. overridden. See `Automatic primary key fields`_ below.
* The ``CREATE TABLE`` SQL in this example is formatted using PostgreSQL * The ``CREATE TABLE`` SQL in this example is formatted using PostgreSQL
syntax, but it's worth noting Django uses SQL tailored to the database syntax, but it's worth noting Django uses SQL tailored to the database
backend specified in your `settings file`_. backend specified in your `settings file`_.
@ -2194,7 +2194,7 @@ Multi-table inheritance
The second type of model inheritance supported by Django is when each model in The second type of model inheritance supported by Django is when each model in
the hierarchy is a model all by itself. Each model corresponds to its own the hierarchy is a model all by itself. Each model corresponds to its own
database table and can be queried and created indvidually. The inheritance database table and can be queried and created individually. The inheritance
relationship introduces links between the child model and each of its parents relationship introduces links between the child model and each of its parents
(via an automatically created ``OneToOneField``). For example:: (via an automatically created ``OneToOneField``). For example::
@ -2242,7 +2242,7 @@ parent: if the child does not specify an ``ordering`` attribute or a
``get_latest_by`` attribute, it will inherit these from its parent. ``get_latest_by`` attribute, it will inherit these from its parent.
If the parent has an ordering and you don't want the child to have any natural If the parent has an ordering and you don't want the child to have any natural
ordering, you can explicity set it to be empty:: ordering, you can explicitly set it to be empty::
class ChildModel(ParentModel): class ChildModel(ParentModel):
... ...