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:
parent
d0c49e7b77
commit
f0bc9426b4
|
@ -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
|
||||||
|
|
|
@ -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):
|
||||||
...
|
...
|
||||||
|
|
Loading…
Reference in New Issue