innov
/
django1
1
0
Fork 0
Code Issues Pull Requests 1 Projects Releases Wiki Activity

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:
Russell Keith-Magee 2010-08-07 14:26:07 +00:00
parent 973fb63e4f
commit 2dc2ed87e5
7 changed files with 33 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
docs/ref/contrib/admin/index.txt
View File

@ -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

11
docs/ref/models/querysets.txt
View File

@ -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()``
~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~

23
docs/releases/1.1-beta-1.txt
View File

@ -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
------------------ ------------------
@ -108,13 +109,13 @@ A couple of small but very useful improvements have been made to the
* The test :class:`Client` now can automatically follow redirects with the * The test :class:`Client` now can automatically follow redirects with the
``follow`` argument to :meth:`Client.get` and :meth:`Client.post`. This ``follow`` argument to :meth:`Client.get` and :meth:`Client.post`. This
makes testing views that issue redirects simpler. makes testing views that issue redirects simpler.
* It's now easier to get at the template context in the response returned * It's now easier to get at the template context in the response returned
the test client: you'll simply access the context as the test client: you'll simply access the context as
``request.context[key]``. The old way, which treats ``request.context`` ``request.context[key]``. The old way, which treats ``request.context``
as a list of contexts, one for each rendered template, is still as a list of contexts, one for each rendered template, is still
available if you need it. available if you need it.
Conditional view processing Conditional view processing
--------------------------- ---------------------------
@ -133,23 +134,23 @@ release, including:
* The :djadmin:`dumpdata` management command now accepts individual * The :djadmin:`dumpdata` management command now accepts individual
model names as arguments, allowing you to export the data just from model names as arguments, allowing you to export the data just from
particular models. particular models.
* There's a new :tfilter:`safeseq` template filter which works just like * There's a new :tfilter:`safeseq` template filter which works just like
:tfilter:`safe` for lists, marking each item in the list as safe. :tfilter:`safe` for lists, marking each item in the list as safe.
* :ref:`Cache backends <topics-cache>` now support ``incr()`` and * :ref:`Cache backends <topics-cache>` now support ``incr()`` and
``decr()`` commands to increment and decrement the value of a cache key. ``decr()`` commands to increment and decrement the value of a cache key.
On cache backends that support atomic increment/decrement -- most On cache backends that support atomic increment/decrement -- most
notably, the memcached backend -- these operations will be atomic, and notably, the memcached backend -- these operations will be atomic, and
quite fast. quite fast.
* Django now can :ref:`easily delegate authentication to the web server * Django now can :ref:`easily delegate authentication to the web server
<howto-auth-remote-user>` via a new authentication backend that supports <howto-auth-remote-user>` via a new authentication backend that supports
the standard ``REMOTE_USER`` environment variable used for this purpose. the standard ``REMOTE_USER`` environment variable used for this purpose.
* There's a new :func:`django.shortcuts.redirect` function that makes it * There's a new :func:`django.shortcuts.redirect` function that makes it
easier to issue redirects given an object, a view name, or a URL. easier to issue redirects given an object, a view name, or a URL.
* The ``postgresql_psycopg2`` backend now supports :ref:`native PostgreSQL * The ``postgresql_psycopg2`` backend now supports :ref:`native PostgreSQL
autocommit <postgresql-notes>`. This is an advanced, PostgreSQL-specific autocommit <postgresql-notes>`. This is an advanced, PostgreSQL-specific
feature, that can make certain read-heavy applications a good deal feature, that can make certain read-heavy applications a good deal
@ -183,7 +184,7 @@ central place to search for open issues:
* http://code.djangoproject.com/timeline * http://code.djangoproject.com/timeline
Please open new tickets if no existing ticket corresponds to a problem you're Please open new tickets if no existing ticket corresponds to a problem you're
running into. running into.
Additionally, discussion of Django development, including progress toward the Additionally, discussion of Django development, including progress toward the
1.1 release, takes place daily on the django-developers mailing list: 1.1 release, takes place daily on the django-developers mailing list:
@ -195,7 +196,7 @@ interested in helping out with Django's development, feel free to join the
discussions there. discussions there.
Django's online documentation also includes pointers on how to contribute to Django's online documentation also includes pointers on how to contribute to
Django: Django:
* :ref:`How to contribute to Django <internals-contributing>` * :ref:`How to contribute to Django <internals-contributing>`

5
docs/releases/1.1.txt
View File

@ -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
-------------------- --------------------

2
docs/topics/db/aggregation.txt
View File

@ -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.

13
docs/topics/db/optimization.txt
View File

@ -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.

6
docs/topics/db/sql.txt
View File

@ -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