diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
index ccea588..8efcc31 100644
a
|
b
|
Though you usually won't create one manually -- you'll go through a :class:`Mana
|
126 | 126 | Usually when you'll interact with a ``QuerySet`` you'll use it by :ref:`chaining |
127 | 127 | filters <chaining-filters>`. To make this work, most ``QuerySet`` methods return new querysets. |
128 | 128 | |
129 | | QuerySet methods that return new QuerySets |
130 | | ------------------------------------------ |
| 129 | Methods that return new QuerySets |
| 130 | --------------------------------- |
131 | 131 | |
132 | 132 | Django provides a range of ``QuerySet`` refinement methods that modify either |
133 | 133 | the types of results returned by the ``QuerySet`` or the way its SQL query is |
134 | 134 | executed. |
135 | 135 | |
136 | | ``filter(**kwargs)`` |
137 | | ~~~~~~~~~~~~~~~~~~~~ |
| 136 | filter |
| 137 | ~~~~~~ |
138 | 138 | |
139 | 139 | .. method:: filter(**kwargs) |
140 | 140 | |
… |
… |
The lookup parameters (``**kwargs``) should be in the format described in
|
145 | 145 | `Field lookups`_ below. Multiple parameters are joined via ``AND`` in the |
146 | 146 | underlying SQL statement. |
147 | 147 | |
148 | | ``exclude(**kwargs)`` |
149 | | ~~~~~~~~~~~~~~~~~~~~~ |
| 148 | exclude |
| 149 | ~~~~~~~ |
150 | 150 | |
151 | 151 | .. method:: exclude(**kwargs) |
152 | 152 | |
… |
… |
In SQL terms, that evaluates to::
|
180 | 180 | |
181 | 181 | Note the second example is more restrictive. |
182 | 182 | |
183 | | ``annotate(*args, **kwargs)`` |
184 | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 183 | annotate |
| 184 | ~~~~~~~~ |
185 | 185 | |
186 | 186 | .. method:: annotate(*args, **kwargs) |
187 | 187 | |
… |
… |
control the name of the annotation::
|
224 | 224 | For an in-depth discussion of aggregation, see :doc:`the topic guide on |
225 | 225 | Aggregation </topics/db/aggregation>`. |
226 | 226 | |
227 | | ``order_by(*fields)`` |
228 | | ~~~~~~~~~~~~~~~~~~~~~ |
| 227 | order_by |
| 228 | ~~~~~~~~ |
229 | 229 | |
230 | 230 | .. method:: order_by(*fields) |
231 | 231 | |
… |
… |
primary key if there is no ``Meta.ordering`` specified. For example::
|
267 | 267 | ...since the ``Blog`` model has no default ordering specified. |
268 | 268 | |
269 | 269 | Be cautious when ordering by fields in related models if you are also using |
270 | | ``distinct()``. See the note in the `distinct()`_ section for an explanation |
271 | | of how related model ordering can change the expected results. |
| 270 | ``distinct()``. See the note in :meth:`distinct` for an explanation of how |
| 271 | related model ordering can change the expected results. |
272 | 272 | |
273 | 273 | It is permissible to specify a multi-valued field to order the results by (for |
274 | 274 | example, a ``ManyToMany`` field). Normally this won't be a sensible thing to |
… |
… |
fields with care and make sure the results are what you expect.
|
280 | 280 | |
281 | 281 | .. versionadded:: 1.0 |
282 | 282 | |
283 | | If you don't want any ordering to be applied to a query, not even the default |
284 | | ordering, call ``order_by()`` with no parameters. |
285 | | |
286 | | .. versionadded:: 1.0 |
287 | | |
288 | 283 | The syntax for ordering across related models has changed. See the `Django 0.96 |
289 | 284 | documentation`_ for the old behaviour. |
290 | 285 | |
… |
… |
There's no way to specify whether ordering should be case sensitive. With
|
294 | 289 | respect to case-sensitivity, Django will order results however your database |
295 | 290 | backend normally orders them. |
296 | 291 | |
| 292 | If you don't want any ordering to be applied to a query, not even the default |
| 293 | ordering, call ``order_by()`` with no parameters. |
| 294 | |
297 | 295 | .. versionadded:: 1.1 |
298 | 296 | |
299 | 297 | You can tell if a query is ordered or not by checking the |
300 | 298 | :attr:`QuerySet.ordered` attribute, which will be ``True`` if the |
301 | 299 | ``QuerySet`` has been ordered in any way. |
302 | 300 | |
303 | | ``reverse()`` |
304 | | ~~~~~~~~~~~~~ |
| 301 | reverse |
| 302 | ~~~~~~~ |
305 | 303 | |
306 | 304 | .. method:: reverse() |
307 | 305 | |
… |
… |
a model which defines a default ordering, or when using
|
330 | 328 | ordering was undefined prior to calling ``reverse()``, and will remain |
331 | 329 | undefined afterward). |
332 | 330 | |
333 | | ``distinct()`` |
334 | | ~~~~~~~~~~~~~~ |
| 331 | distinct |
| 332 | ~~~~~~~~ |
335 | 333 | |
336 | 334 | .. method:: distinct() |
337 | 335 | |
… |
… |
query spans multiple tables, it's possible to get duplicate results when a
|
345 | 343 | ``QuerySet`` is evaluated. That's when you'd use ``distinct()``. |
346 | 344 | |
347 | 345 | .. note:: |
348 | | Any fields used in an `order_by(*fields)`_ call are included in the SQL |
| 346 | Any fields used in an :meth:`order_by` call are included in the SQL |
349 | 347 | ``SELECT`` columns. This can sometimes lead to unexpected results when |
350 | 348 | used in conjunction with ``distinct()``. If you order by fields from a |
351 | 349 | related model, those fields will be added to the selected columns and they |
… |
… |
query spans multiple tables, it's possible to get duplicate results when a
|
363 | 361 | ``values()`` together, be careful when ordering by fields not in the |
364 | 362 | ``values()`` call. |
365 | 363 | |
366 | | ``values(*fields)`` |
367 | | ~~~~~~~~~~~~~~~~~~~ |
| 364 | values |
| 365 | ~~~~~~ |
368 | 366 | |
369 | 367 | .. method:: values(*fields) |
370 | 368 | |
… |
… |
A few subtleties that are worth mentioning:
|
419 | 417 | |
420 | 418 | >>> Entry.objects.values('blog_id') |
421 | 419 | [{'blog_id': 1}, ...] |
| 420 | |
422 | 421 | * When using ``values()`` together with ``distinct()``, be aware that |
423 | | ordering can affect the results. See the note in the `distinct()`_ |
424 | | section, above, for details. |
| 422 | ordering can affect the results. See the note in :meth:`distinct` for |
| 423 | details. |
| 424 | |
425 | 425 | * If you use a ``values()`` clause after an ``extra()`` clause, |
426 | 426 | any fields defined by a ``select`` argument in the ``extra()`` |
427 | 427 | must be explicitly included in the ``values()`` clause. However, |
… |
… |
and ``ManyToManyField`` attributes::
|
472 | 472 | pronounced if you include multiple such fields in your ``values()`` query, |
473 | 473 | in which case all possible combinations will be returned. |
474 | 474 | |
475 | | ``values_list(*fields)`` |
476 | | ~~~~~~~~~~~~~~~~~~~~~~~~ |
| 475 | values_list |
| 476 | ~~~~~~~~~~~ |
477 | 477 | |
478 | 478 | .. method:: values_list(*fields) |
479 | 479 | |
… |
… |
It is an error to pass in ``flat`` when there is more than one field.
|
502 | 502 | If you don't pass any values to ``values_list()``, it will return all the |
503 | 503 | fields in the model, in the order they were declared. |
504 | 504 | |
505 | | ``dates(field, kind, order='ASC')`` |
506 | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 505 | dates |
| 506 | ~~~~~ |
507 | 507 | |
508 | 508 | .. method:: dates(field, kind, order='ASC') |
509 | 509 | |
… |
… |
Examples::
|
538 | 538 | >>> Entry.objects.filter(headline__contains='Lennon').dates('pub_date', 'day') |
539 | 539 | [datetime.datetime(2005, 3, 20)] |
540 | 540 | |
541 | | ``none()`` |
542 | | ~~~~~~~~~~ |
| 541 | none |
| 542 | ~~~~ |
543 | 543 | |
544 | 544 | .. method:: none() |
545 | 545 | |
… |
… |
Examples::
|
555 | 555 | >>> Entry.objects.none() |
556 | 556 | [] |
557 | 557 | |
558 | | ``all()`` |
559 | | ~~~~~~~~~ |
| 558 | all |
| 559 | ~~~ |
560 | 560 | |
561 | 561 | .. method:: all() |
562 | 562 | |
… |
… |
definitely have a ``QuerySet`` to work with.
|
570 | 570 | |
571 | 571 | .. _select-related: |
572 | 572 | |
573 | | ``select_related()`` |
574 | | ~~~~~~~~~~~~~~~~~~~~ |
| 573 | select_related |
| 574 | ~~~~~~~~~~~~~~ |
575 | 575 | |
576 | 576 | .. method:: select_related() |
577 | 577 | |
… |
… |
related object.
|
691 | 691 | ``OneToOneFields`` will not be traversed in the reverse direction if you |
692 | 692 | are performing a depth-based ``select_related``. |
693 | 693 | |
694 | | ``extra(select=None, where=None, params=None, tables=None, order_by=None, select_params=None)`` |
695 | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 694 | extra |
| 695 | ~~~~~ |
696 | 696 | |
697 | 697 | .. method:: extra(select=None, where=None, params=None, tables=None, order_by=None, select_params=None) |
698 | 698 | |
… |
… |
of the arguments is required, but you should use at least one of them.
|
854 | 854 | |
855 | 855 | Entry.objects.extra(where=['headline=%s'], params=['Lennon']) |
856 | 856 | |
857 | | ``defer(*fields)`` |
858 | | ~~~~~~~~~~~~~~~~~~ |
| 857 | defer |
| 858 | ~~~~~ |
859 | 859 | |
860 | 860 | .. method:: defer(*fields) |
861 | 861 | |
… |
… |
eventually).
|
914 | 914 | bother using ``defer()``; leave it until your query construction has |
915 | 915 | settled down and you understand where the hot-points are. |
916 | 916 | |
917 | | ``only(*fields)`` |
918 | | ~~~~~~~~~~~~~~~~~ |
| 917 | only |
| 918 | ~~~~ |
919 | 919 | |
920 | 920 | .. method:: only(*fields) |
921 | 921 | |
… |
… |
logically::
|
952 | 952 | # existing set of fields). |
953 | 953 | Entry.objects.defer("body").only("headline", "body") |
954 | 954 | |
955 | | ``using(alias)`` |
956 | | ~~~~~~~~~~~~~~~~ |
| 955 | using |
| 956 | ~~~~~ |
957 | 957 | |
958 | 958 | .. method:: using(alias) |
959 | 959 | |
… |
… |
For example::
|
973 | 973 | >>> Entry.objects.using('backup') |
974 | 974 | |
975 | 975 | |
976 | | QuerySet methods that do not return QuerySets |
977 | | --------------------------------------------- |
| 976 | Methods that do not return QuerySets |
| 977 | ------------------------------------ |
978 | 978 | |
979 | 979 | The following ``QuerySet`` methods evaluate the ``QuerySet`` and return |
980 | 980 | something *other than* a ``QuerySet``. |
… |
… |
something *other than* a ``QuerySet``.
|
982 | 982 | These methods do not use a cache (see :ref:`caching-and-querysets`). Rather, |
983 | 983 | they query the database each time they're called. |
984 | 984 | |
985 | | ``get(**kwargs)`` |
986 | | ~~~~~~~~~~~~~~~~~ |
| 985 | get |
| 986 | ~~~ |
987 | 987 | |
988 | 988 | .. method:: get(**kwargs) |
989 | 989 | |
… |
… |
The ``DoesNotExist`` exception inherits from
|
1011 | 1011 | except ObjectDoesNotExist: |
1012 | 1012 | print "Either the entry or blog doesn't exist." |
1013 | 1013 | |
1014 | | ``create(**kwargs)`` |
1015 | | ~~~~~~~~~~~~~~~~~~~~ |
| 1014 | create |
| 1015 | ~~~~~~ |
1016 | 1016 | |
1017 | 1017 | .. method:: create(**kwargs) |
1018 | 1018 | |
… |
… |
database, a call to ``create()`` will fail with an ``IntegrityError`` since
|
1035 | 1035 | primary keys must be unique. So remember to be prepared to handle the |
1036 | 1036 | exception if you are using manual primary keys. |
1037 | 1037 | |
1038 | | ``get_or_create(**kwargs)`` |
1039 | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 1038 | get_or_create |
| 1039 | ~~~~~~~~~~~~~ |
1040 | 1040 | |
1041 | 1041 | .. method:: get_or_create(**kwargs) |
1042 | 1042 | |
… |
… |
has a side effect on your data. For more, see `Safe methods`_ in the HTTP spec.
|
1105 | 1105 | |
1106 | 1106 | .. _Safe methods: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1 |
1107 | 1107 | |
1108 | | ``count()`` |
1109 | | ~~~~~~~~~~~ |
| 1108 | count |
| 1109 | ~~~~~ |
1110 | 1110 | |
1111 | 1111 | .. method:: count() |
1112 | 1112 | |
… |
… |
Depending on which database you're using (e.g. PostgreSQL vs. MySQL),
|
1131 | 1131 | is an underlying implementation quirk that shouldn't pose any real-world |
1132 | 1132 | problems. |
1133 | 1133 | |
1134 | | ``in_bulk(id_list)`` |
1135 | | ~~~~~~~~~~~~~~~~~~~~ |
| 1134 | in_bulk |
| 1135 | ~~~~~~~ |
1136 | 1136 | |
1137 | 1137 | .. method:: in_bulk(id_list) |
1138 | 1138 | |
… |
… |
Example::
|
1150 | 1150 | |
1151 | 1151 | If you pass ``in_bulk()`` an empty list, you'll get an empty dictionary. |
1152 | 1152 | |
1153 | | ``iterator()`` |
1154 | | ~~~~~~~~~~~~~~ |
| 1153 | iterator |
| 1154 | ~~~~~~~~ |
1155 | 1155 | |
1156 | 1156 | .. method:: iterator() |
1157 | 1157 | |
… |
… |
been evaluated will force it to evaluate again, repeating the query.
|
1168 | 1168 | |
1169 | 1169 | .. _iterator: http://www.python.org/dev/peps/pep-0234/ |
1170 | 1170 | |
1171 | | ``latest(field_name=None)`` |
1172 | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 1171 | latest |
| 1172 | ~~~~~~ |
1173 | 1173 | |
1174 | 1174 | .. method:: latest(field_name=None) |
1175 | 1175 | |
… |
… |
exist with the given parameters.
|
1190 | 1190 | |
1191 | 1191 | Note ``latest()`` exists purely for convenience and readability. |
1192 | 1192 | |
1193 | | ``aggregate(*args, **kwargs)`` |
1194 | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 1193 | aggregate |
| 1194 | ~~~~~~~~~ |
1195 | 1195 | |
1196 | 1196 | .. method:: aggregate(*args, **kwargs) |
1197 | 1197 | |
… |
… |
control the name of the aggregation value that is returned::
|
1224 | 1224 | For an in-depth discussion of aggregation, see :doc:`the topic guide on |
1225 | 1225 | Aggregation </topics/db/aggregation>`. |
1226 | 1226 | |
1227 | | ``exists()`` |
1228 | | ~~~~~~~~~~~~ |
| 1227 | exists |
| 1228 | ~~~~~~ |
1229 | 1229 | |
1230 | 1230 | .. method:: exists() |
1231 | 1231 | |
… |
… |
that it will be at some point, then using ``some_query_set.exists()`` will do
|
1240 | 1240 | more overall work (an additional query) than simply using |
1241 | 1241 | ``bool(some_query_set)``. |
1242 | 1242 | |
1243 | | ``update(**kwargs)`` |
1244 | | ~~~~~~~~~~~~~~~~~~~~ |
| 1243 | update |
| 1244 | ~~~~~~ |
1245 | 1245 | |
1246 | 1246 | .. method:: update(**kwargs) |
1247 | 1247 | |
… |
… |
The ``update()`` method does a bulk update and does not call any ``save()``
|
1265 | 1265 | methods on your models, nor does it emit the ``pre_save`` or ``post_save`` |
1266 | 1266 | signals (which are a consequence of calling ``save()``). |
1267 | 1267 | |
1268 | | ``delete()`` |
1269 | | ~~~~~~~~~~~~~~~~~~~~ |
| 1268 | delete |
| 1269 | ~~~~~~ |
1270 | 1270 | |
1271 | 1271 | .. method:: delete() |
1272 | 1272 | |
… |
… |
Django provides the following aggregation functions in the
|
1805 | 1805 | aggregate functions, see |
1806 | 1806 | :doc:`the topic guide on aggregation </topics/db/aggregation>`. |
1807 | 1807 | |
1808 | | ``Avg`` |
1809 | | ~~~~~~~ |
| 1808 | Avg |
| 1809 | ~~~ |
1810 | 1810 | |
1811 | 1811 | .. class:: Avg(field) |
1812 | 1812 | |
… |
… |
Returns the mean value of the given field.
|
1815 | 1815 | * Default alias: ``<field>__avg`` |
1816 | 1816 | * Return type: float |
1817 | 1817 | |
1818 | | ``Count`` |
1819 | | ~~~~~~~~~ |
| 1818 | Count |
| 1819 | ~~~~~ |
1820 | 1820 | |
1821 | 1821 | .. class:: Count(field, distinct=False) |
1822 | 1822 | |
… |
… |
Has one optional argument:
|
1832 | 1832 | If distinct=True, the count will only include unique instances. This has |
1833 | 1833 | the SQL equivalent of ``COUNT(DISTINCT field)``. Default value is ``False``. |
1834 | 1834 | |
1835 | | ``Max`` |
1836 | | ~~~~~~~ |
| 1835 | Max |
| 1836 | ~~~ |
1837 | 1837 | |
1838 | 1838 | .. class:: Max(field) |
1839 | 1839 | |
… |
… |
Returns the maximum value of the given field.
|
1842 | 1842 | * Default alias: ``<field>__max`` |
1843 | 1843 | * Return type: same as input field |
1844 | 1844 | |
1845 | | ``Min`` |
1846 | | ~~~~~~~ |
| 1845 | Min |
| 1846 | ~~~ |
1847 | 1847 | |
1848 | 1848 | .. class:: Min(field) |
1849 | 1849 | |
… |
… |
Returns the minimum value of the given field.
|
1852 | 1852 | * Default alias: ``<field>__min`` |
1853 | 1853 | * Return type: same as input field |
1854 | 1854 | |
1855 | | ``StdDev`` |
1856 | | ~~~~~~~~~~ |
| 1855 | StdDev |
| 1856 | ~~~~~~ |
1857 | 1857 | |
1858 | 1858 | .. class:: StdDev(field, sample=False) |
1859 | 1859 | |
… |
… |
Has one optional argument:
|
1875 | 1875 | available as an extension module for SQLite. Consult the SQlite |
1876 | 1876 | documentation for instructions on obtaining and installing this extension. |
1877 | 1877 | |
1878 | | ``Sum`` |
1879 | | ~~~~~~~ |
| 1878 | Sum |
| 1879 | ~~~ |
1880 | 1880 | |
1881 | 1881 | .. class:: Sum(field) |
1882 | 1882 | |
… |
… |
Computes the sum of all values of the given field.
|
1885 | 1885 | * Default alias: ``<field>__sum`` |
1886 | 1886 | * Return type: same as input field |
1887 | 1887 | |
1888 | | ``Variance`` |
1889 | | ~~~~~~~~~~~~ |
| 1888 | Variance |
| 1889 | ~~~~~~~~ |
1890 | 1890 | |
1891 | 1891 | .. class:: Variance(field, sample=False) |
1892 | 1892 | |