Fixed #11800 -- Updated Sphinx metadata in queryset docs. Thanks to timo for the patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@13548 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
973fb63e4f
commit
2dc2ed87e5
|
@ -474,17 +474,16 @@ change list page. By default, this is set to ``100``.
|
||||||
|
|
||||||
.. attribute:: ModelAdmin.list_select_related
|
.. attribute:: ModelAdmin.list_select_related
|
||||||
|
|
||||||
Set ``list_select_related`` to tell Django to use ``select_related()`` in
|
Set ``list_select_related`` to tell Django to use
|
||||||
retrieving the list of objects on the admin change list page. This can save you
|
:meth:`~django.db.models.QuerySet.select_related` in retrieving the list of
|
||||||
a bunch of database queries.
|
objects on the admin change list page. This can save you a bunch of database
|
||||||
|
queries.
|
||||||
|
|
||||||
The value should be either ``True`` or ``False``. Default is ``False``.
|
The value should be either ``True`` or ``False``. Default is ``False``.
|
||||||
|
|
||||||
Note that Django will use ``select_related()``, regardless of this setting,
|
Note that Django will use :meth:`~django.db.models.QuerySet.select_related`,
|
||||||
if one of the ``list_display`` fields is a ``ForeignKey``.
|
regardless of this setting, if one of the ``list_display`` fields is a
|
||||||
|
``ForeignKey``.
|
||||||
For more on ``select_related()``, see
|
|
||||||
:ref:`the select_related() docs <select-related>`.
|
|
||||||
|
|
||||||
.. attribute:: ModelAdmin.inlines
|
.. attribute:: ModelAdmin.inlines
|
||||||
|
|
||||||
|
|
|
@ -332,8 +332,6 @@ a model which defines a default ordering, or when using
|
||||||
ordering was undefined prior to calling ``reverse()``, and will remain
|
ordering was undefined prior to calling ``reverse()``, and will remain
|
||||||
undefined afterward).
|
undefined afterward).
|
||||||
|
|
||||||
.. _queryset-distinct:
|
|
||||||
|
|
||||||
``distinct()``
|
``distinct()``
|
||||||
~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
@ -367,9 +365,6 @@ query spans multiple tables, it's possible to get duplicate results when a
|
||||||
``values()`` together, be careful when ordering by fields not in the
|
``values()`` together, be careful when ordering by fields not in the
|
||||||
``values()`` call.
|
``values()`` call.
|
||||||
|
|
||||||
|
|
||||||
.. _queryset-values:
|
|
||||||
|
|
||||||
``values(*fields)``
|
``values(*fields)``
|
||||||
~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
@ -679,8 +674,6 @@ related object.
|
||||||
``OneToOneFields`` will not be traversed in the reverse direction if you
|
``OneToOneFields`` will not be traversed in the reverse direction if you
|
||||||
are performing a depth-based ``select_related``.
|
are performing a depth-based ``select_related``.
|
||||||
|
|
||||||
.. _queryset-extra:
|
|
||||||
|
|
||||||
``extra(select=None, where=None, params=None, tables=None, order_by=None, select_params=None)``
|
``extra(select=None, where=None, params=None, tables=None, order_by=None, select_params=None)``
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
@ -843,8 +836,6 @@ of the arguments is required, but you should use at least one of them.
|
||||||
|
|
||||||
Entry.objects.extra(where=['headline=%s'], params=['Lennon'])
|
Entry.objects.extra(where=['headline=%s'], params=['Lennon'])
|
||||||
|
|
||||||
.. _queryset-defer:
|
|
||||||
|
|
||||||
``defer(*fields)``
|
``defer(*fields)``
|
||||||
~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
@ -1143,8 +1134,6 @@ Example::
|
||||||
|
|
||||||
If you pass ``in_bulk()`` an empty list, you'll get an empty dictionary.
|
If you pass ``in_bulk()`` an empty list, you'll get an empty dictionary.
|
||||||
|
|
||||||
.. _queryset-iterator:
|
|
||||||
|
|
||||||
``iterator()``
|
``iterator()``
|
||||||
~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
|
|
@ -71,8 +71,9 @@ processing to convert them to Python objects. If you know you don't need those
|
||||||
particular fields, you can now tell Django not to retrieve them from the
|
particular fields, you can now tell Django not to retrieve them from the
|
||||||
database.
|
database.
|
||||||
|
|
||||||
You'll do this with the :ref:`new queryset methods <queryset-defer>`
|
You'll do this with the new queryset methods
|
||||||
``defer()`` and ``only()``.
|
:meth:`~django.db.models.QuerySet.defer` and
|
||||||
|
:meth:`~django.db.models.QuerySet.only`.
|
||||||
|
|
||||||
New admin features
|
New admin features
|
||||||
------------------
|
------------------
|
||||||
|
|
|
@ -258,8 +258,9 @@ processing to convert them to Python objects. If you know you don't need those
|
||||||
particular fields, you can now tell Django not to retrieve them from the
|
particular fields, you can now tell Django not to retrieve them from the
|
||||||
database.
|
database.
|
||||||
|
|
||||||
You'll do this with the :ref:`new queryset methods <queryset-defer>`
|
You'll do this with the new queryset methods
|
||||||
``defer()`` and ``only()``.
|
:meth:`~django.db.models.QuerySet.defer` and
|
||||||
|
:meth:`~django.db.models.QuerySet.only`.
|
||||||
|
|
||||||
Testing improvements
|
Testing improvements
|
||||||
--------------------
|
--------------------
|
||||||
|
|
|
@ -353,7 +353,7 @@ without any harmful effects, since that is already playing a role in the
|
||||||
query.
|
query.
|
||||||
|
|
||||||
This behavior is the same as that noted in the queryset documentation for
|
This behavior is the same as that noted in the queryset documentation for
|
||||||
:ref:`distinct() <queryset-distinct>` and the general rule is the same:
|
:meth:`~django.db.models.QuerySet.distinct` and the general rule is the same:
|
||||||
normally you won't want extra columns playing a part in the result, so clear
|
normally you won't want extra columns playing a part in the result, so clear
|
||||||
out the ordering, or at least make sure it's restricted only to those fields
|
out the ordering, or at least make sure it's restricted only to those fields
|
||||||
you also select in a ``values()`` call.
|
you also select in a ``values()`` call.
|
||||||
|
|
|
@ -101,7 +101,7 @@ Use ``iterator()``
|
||||||
|
|
||||||
When you have a lot of objects, the caching behaviour of the ``QuerySet`` can
|
When you have a lot of objects, the caching behaviour of the ``QuerySet`` can
|
||||||
cause a large amount of memory to be used. In this case,
|
cause a large amount of memory to be used. In this case,
|
||||||
:ref:`QuerySet.iterator() <queryset-iterator>` may help.
|
:meth:`~django.db.models.QuerySet.iterator()` may help.
|
||||||
|
|
||||||
Do database work in the database rather than in Python
|
Do database work in the database rather than in Python
|
||||||
======================================================
|
======================================================
|
||||||
|
@ -121,9 +121,9 @@ If these aren't enough to generate the SQL you need:
|
||||||
Use ``QuerySet.extra()``
|
Use ``QuerySet.extra()``
|
||||||
------------------------
|
------------------------
|
||||||
|
|
||||||
A less portable but more powerful method is :ref:`QuerySet.extra()
|
A less portable but more powerful method is
|
||||||
<queryset-extra>`, which allows some SQL to be explicitly added to the query.
|
:meth:`~django.db.models.QuerySet.extra()`, which allows some SQL to be
|
||||||
If that still isn't powerful enough:
|
explicitly added to the query. If that still isn't powerful enough:
|
||||||
|
|
||||||
Use raw SQL
|
Use raw SQL
|
||||||
-----------
|
-----------
|
||||||
|
@ -159,7 +159,7 @@ Use ``QuerySet.values()`` and ``values_list()``
|
||||||
-----------------------------------------------
|
-----------------------------------------------
|
||||||
|
|
||||||
When you just want a dict/list of values, and don't need ORM model objects, make
|
When you just want a dict/list of values, and don't need ORM model objects, make
|
||||||
appropriate usage of :ref:`QuerySet.values() <queryset-values>`.
|
appropriate usage of :meth:`~django.db.models.QuerySet.values()`.
|
||||||
These can be useful for replacing model objects in template code - as long as
|
These can be useful for replacing model objects in template code - as long as
|
||||||
the dicts you supply have the same attributes as those used in the template, you
|
the dicts you supply have the same attributes as those used in the template, you
|
||||||
are fine.
|
are fine.
|
||||||
|
@ -167,7 +167,8 @@ are fine.
|
||||||
Use ``QuerySet.defer()`` and ``only()``
|
Use ``QuerySet.defer()`` and ``only()``
|
||||||
---------------------------------------
|
---------------------------------------
|
||||||
|
|
||||||
Use :ref:`defer() and only() <queryset-defer>` if there are database columns you
|
Use :meth:`~django.db.models.QuerySet.defer()` and
|
||||||
|
:meth:`~django.db.models.QuerySet.only()` if there are database columns you
|
||||||
know that you won't need (or won't need in most cases) to avoid loading
|
know that you won't need (or won't need in most cases) to avoid loading
|
||||||
them. Note that if you *do* use them, the ORM will have to go and get them in a
|
them. Note that if you *do* use them, the ORM will have to go and get them in a
|
||||||
separate query, making this a pessimization if you use it inappropriately.
|
separate query, making this a pessimization if you use it inappropriately.
|
||||||
|
|
|
@ -116,9 +116,9 @@ Fields may also be left out::
|
||||||
|
|
||||||
>>> people = Person.objects.raw('SELECT id, first_name FROM myapp_person')
|
>>> people = Person.objects.raw('SELECT id, first_name FROM myapp_person')
|
||||||
|
|
||||||
The ``Person`` objects returned by this query will be :ref:`deferred
|
The ``Person`` objects returned by this query will be deferred model instances
|
||||||
<queryset-defer>` model instances. This means that the fields that are omitted
|
(see :meth:`~django.db.models.QuerySet.defer()`). This means that the fields
|
||||||
from the query will be loaded on demand. For example::
|
that are omitted from the query will be loaded on demand. For example::
|
||||||
|
|
||||||
>>> for p in Person.objects.raw('SELECT id, first_name FROM myapp_person'):
|
>>> for p in Person.objects.raw('SELECT id, first_name FROM myapp_person'):
|
||||||
... print p.first_name, # This will be retrieved by the original query
|
... print p.first_name, # This will be retrieved by the original query
|
||||||
|
|
Loading…
Reference in New Issue