Fixed doc references to `django.db.models.query.QuerySet` and converted some tabs that were introduced in r16699 to spaces.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@16915 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
ec5bfed57a
commit
2eadc418af
|
@ -321,9 +321,9 @@ will get you started for now.
|
|||
A shortcut: get_object_or_404()
|
||||
-------------------------------
|
||||
|
||||
It's a very common idiom to use :meth:`~django.db.models.QuerySet.get` and raise
|
||||
:exc:`~django.http.Http404` if the object doesn't exist. Django provides a
|
||||
shortcut. Here's the ``detail()`` view, rewritten::
|
||||
It's a very common idiom to use :meth:`~django.db.models.query.QuerySet.get`
|
||||
and raise :exc:`~django.http.Http404` if the object doesn't exist. Django
|
||||
provides a shortcut. Here's the ``detail()`` view, rewritten::
|
||||
|
||||
from django.shortcuts import render_to_response, get_object_or_404
|
||||
# ...
|
||||
|
@ -333,8 +333,8 @@ shortcut. Here's the ``detail()`` view, rewritten::
|
|||
|
||||
The :func:`~django.shortcuts.get_object_or_404` function takes a Django model
|
||||
as its first argument and an arbitrary number of keyword arguments, which it
|
||||
passes to the module's :meth:`~django.db.models.QuerySet.get` function. It
|
||||
raises :exc:`~django.http.Http404` if the object doesn't exist.
|
||||
passes to the module's :meth:`~django.db.models.query.QuerySet.get` function.
|
||||
It raises :exc:`~django.http.Http404` if the object doesn't exist.
|
||||
|
||||
.. admonition:: Philosophy
|
||||
|
||||
|
@ -349,9 +349,9 @@ raises :exc:`~django.http.Http404` if the object doesn't exist.
|
|||
|
||||
There's also a :func:`~django.shortcuts.get_list_or_404` function, which works
|
||||
just as :func:`~django.shortcuts.get_object_or_404` -- except using
|
||||
:meth:`~django.db.models.QuerySet.filter` instead of
|
||||
:meth:`~django.db.models.QuerySet.get`. It raises :exc:`~django.http.Http404` if
|
||||
the list is empty.
|
||||
:meth:`~django.db.models.query.QuerySet.filter` instead of
|
||||
:meth:`~django.db.models.query.QuerySet.get`. It raises
|
||||
:exc:`~django.http.Http404` if the list is empty.
|
||||
|
||||
Write a 404 (page not found) view
|
||||
=================================
|
||||
|
|
|
@ -388,7 +388,7 @@ MultipleObjectTemplateResponseMixin
|
|||
that operate upon a list of object instances. Requires that the view it is
|
||||
mixed with provides ``self.object_list``, the list of object instances that
|
||||
the view is operating on. ``self.object_list`` may be, but is not required
|
||||
to be, a :class:`~django.db.models.Queryset`.
|
||||
to be, a :class:`~django.db.models.query.QuerySet`.
|
||||
|
||||
**Extends**
|
||||
|
||||
|
@ -814,7 +814,7 @@ BaseDateListView
|
|||
Returns the list of dates of type ``date_type`` for which
|
||||
``queryset`` contains entries. For example, ``get_date_list(qs,
|
||||
'year')`` will return the list of years for which ``qs`` has entries.
|
||||
See :meth:`~django.db.models.QuerySet.dates()` for the
|
||||
See :meth:`~django.db.models.query.QuerySet.dates()` for the
|
||||
ways that the ``date_type`` argument can be used.
|
||||
|
||||
|
||||
|
|
|
@ -23,8 +23,9 @@ models. For example, here's the user module from Django's built-in
|
|||
.. warning::
|
||||
|
||||
The "delete selected objects" action uses :meth:`QuerySet.delete()
|
||||
<django.db.models.QuerySet.delete>` for efficiency reasons, which has an
|
||||
important caveat: your model's ``delete()`` method will not be called.
|
||||
<django.db.models.query.QuerySet.delete>` for efficiency reasons, which
|
||||
has an important caveat: your model's ``delete()`` method will not be
|
||||
called.
|
||||
|
||||
If you wish to override this behavior, simply write a custom action which
|
||||
accomplishes deletion in your preferred manner -- for example, by calling
|
||||
|
@ -74,8 +75,8 @@ three arguments:
|
|||
|
||||
* The current :class:`ModelAdmin`
|
||||
* An :class:`~django.http.HttpRequest` representing the current request,
|
||||
* A :class:`~django.db.models.QuerySet` containing the set of objects
|
||||
selected by the user.
|
||||
* A :class:`~django.db.models.query.QuerySet` containing the set of
|
||||
objects selected by the user.
|
||||
|
||||
Our publish-these-articles function won't need the :class:`ModelAdmin` or the
|
||||
request object, but we will use the queryset::
|
||||
|
|
|
@ -713,13 +713,14 @@ subclass::
|
|||
.. attribute:: ModelAdmin.list_select_related
|
||||
|
||||
Set ``list_select_related`` to tell Django to use
|
||||
:meth:`~django.db.models.QuerySet.select_related` in retrieving the list of
|
||||
objects on the admin change list page. This can save you a bunch of
|
||||
database queries.
|
||||
:meth:`~django.db.models.query.QuerySet.select_related` in retrieving
|
||||
the list of 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``.
|
||||
|
||||
Note that Django will use :meth:`~django.db.models.QuerySet.select_related`,
|
||||
Note that Django will use
|
||||
:meth:`~django.db.models.query.QuerySet.select_related`,
|
||||
regardless of this setting if one of the ``list_display`` fields is a
|
||||
``ForeignKey``.
|
||||
|
||||
|
@ -1182,9 +1183,9 @@ templates used by the :class:`ModelAdmin` views:
|
|||
.. method:: ModelAdmin.queryset(self, request)
|
||||
|
||||
The ``queryset`` method on a ``ModelAdmin`` returns a
|
||||
:class:`~django.db.models.QuerySet` of all model instances that can be
|
||||
edited by the admin site. One use case for overriding this method is
|
||||
to show objects owned by the logged-in user::
|
||||
:class:`~django.db.models.query.QuerySet` of all model instances that
|
||||
can be edited by the admin site. One use case for overriding this method
|
||||
is to show objects owned by the logged-in user::
|
||||
|
||||
class MyModelAdmin(admin.ModelAdmin):
|
||||
def queryset(self, request):
|
||||
|
|
|
@ -116,7 +116,8 @@ model it represents, or to retrieve objects from that model:
|
|||
|
||||
Takes a set of valid :ref:`lookup arguments <field-lookups-intro>` for the
|
||||
model the :class:`~django.contrib.contenttypes.models.ContentType`
|
||||
represents, and does :meth:`a get() lookup <django.db.models.QuerySet.get>`
|
||||
represents, and does
|
||||
:meth:`a get() lookup <django.db.models.query.QuerySet.get>`
|
||||
on that model, returning the corresponding object.
|
||||
|
||||
.. method:: ContentType.model_class()
|
||||
|
@ -416,9 +417,9 @@ might be tempted to try something like::
|
|||
|
||||
This will not work correctly, however. The generic relation adds extra filters
|
||||
to the queryset to ensure the correct content type, but the
|
||||
:meth:`~django.db.models.QuerySet.aggregate` method doesn't take them into
|
||||
account. For now, if you need aggregates on generic relations, you'll need
|
||||
to calculate them without using the aggregation API.
|
||||
:meth:`~django.db.models.query.QuerySet.aggregate` method doesn't take them
|
||||
into account. For now, if you need aggregates on generic relations, you'll
|
||||
need to calculate them without using the aggregation API.
|
||||
|
||||
Generic relations in forms and admin
|
||||
------------------------------------
|
||||
|
|
|
@ -119,7 +119,7 @@ A complete reference can be found in the :ref:`spatial lookup reference
|
|||
.. note::
|
||||
|
||||
GeoDjango constructs spatial SQL with the :class:`GeoQuerySet`, a
|
||||
subclass of :class:`~django.db.models.QuerySet`. The
|
||||
subclass of :class:`~django.db.models.query.QuerySet`. The
|
||||
:class:`GeoManager` instance attached to your model is what
|
||||
enables use of :class:`GeoQuerySet`.
|
||||
|
||||
|
|
|
@ -89,7 +89,7 @@ Django quotes column and table names behind the scenes.
|
|||
|
||||
get_latest_by = "order_date"
|
||||
|
||||
See the docs for :meth:`~django.db.models.QuerySet.latest` for more.
|
||||
See the docs for :meth:`~django.db.models.query.QuerySet.latest` for more.
|
||||
|
||||
``managed``
|
||||
-----------
|
||||
|
|
|
@ -810,6 +810,7 @@ of the arguments is required, but you should use at least one of them.
|
|||
way, so you can rely upon the alias name to not change.
|
||||
|
||||
* ``order_by``
|
||||
|
||||
If you need to order the resulting queryset using some of the new
|
||||
fields or tables you have included via ``extra()`` use the ``order_by``
|
||||
parameter to ``extra()`` and pass in a sequence of strings. These
|
||||
|
@ -831,6 +832,7 @@ of the arguments is required, but you should use at least one of them.
|
|||
and it will behave as you expect (adding new constraints each time).
|
||||
|
||||
* ``params``
|
||||
|
||||
The ``where`` parameter described above may use standard Python
|
||||
database string placeholders — ``'%s'`` to indicate parameters the
|
||||
database engine should automatically quote. The ``params`` argument is
|
||||
|
|
|
@ -70,8 +70,8 @@ particular fields, you can now tell Django not to retrieve them from the
|
|||
database.
|
||||
|
||||
You'll do this with the new queryset methods
|
||||
:meth:`~django.db.models.QuerySet.defer` and
|
||||
:meth:`~django.db.models.QuerySet.only`.
|
||||
:meth:`~django.db.models.query.QuerySet.defer` and
|
||||
:meth:`~django.db.models.query.QuerySet.only`.
|
||||
|
||||
New admin features
|
||||
------------------
|
||||
|
|
|
@ -257,8 +257,8 @@ particular fields, you can now tell Django not to retrieve them from the
|
|||
database.
|
||||
|
||||
You'll do this with the new queryset methods
|
||||
:meth:`~django.db.models.QuerySet.defer` and
|
||||
:meth:`~django.db.models.QuerySet.only`.
|
||||
:meth:`~django.db.models.query.QuerySet.defer` and
|
||||
:meth:`~django.db.models.query.QuerySet.only`.
|
||||
|
||||
Testing improvements
|
||||
--------------------
|
||||
|
|
|
@ -349,10 +349,10 @@ without any harmful effects, since that is already playing a role in the
|
|||
query.
|
||||
|
||||
This behavior is the same as that noted in the queryset documentation for
|
||||
: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
|
||||
out the ordering, or at least make sure it's restricted only to those fields
|
||||
you also select in a ``values()`` call.
|
||||
:meth:`~django.db.models.query.QuerySet.distinct` and the general rule is the
|
||||
same: 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 you also select in a ``values()`` call.
|
||||
|
||||
.. note::
|
||||
You might reasonably ask why Django doesn't remove the extraneous columns
|
||||
|
|
|
@ -101,7 +101,7 @@ Use ``iterator()``
|
|||
|
||||
When you have a lot of objects, the caching behavior of the ``QuerySet`` can
|
||||
cause a large amount of memory to be used. In this case,
|
||||
:meth:`~django.db.models.QuerySet.iterator()` may help.
|
||||
:meth:`~django.db.models.query.QuerySet.iterator()` may help.
|
||||
|
||||
Do database work in the database rather than in Python
|
||||
======================================================
|
||||
|
@ -122,7 +122,7 @@ Use ``QuerySet.extra()``
|
|||
------------------------
|
||||
|
||||
A less portable but more powerful method is
|
||||
:meth:`~django.db.models.QuerySet.extra()`, which allows some SQL to be
|
||||
:meth:`~django.db.models.query.QuerySet.extra()`, which allows some SQL to be
|
||||
explicitly added to the query. If that still isn't powerful enough:
|
||||
|
||||
Use raw SQL
|
||||
|
@ -159,7 +159,8 @@ Use ``QuerySet.values()`` and ``values_list()``
|
|||
-----------------------------------------------
|
||||
|
||||
When you just want a ``dict`` or ``list`` of values, and don't need ORM model
|
||||
objects, make appropriate usage of :meth:`~django.db.models.QuerySet.values()`.
|
||||
objects, make appropriate usage of
|
||||
:meth:`~django.db.models.query.QuerySet.values()`.
|
||||
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 are fine.
|
||||
|
@ -167,9 +168,9 @@ you are fine.
|
|||
Use ``QuerySet.defer()`` and ``only()``
|
||||
---------------------------------------
|
||||
|
||||
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
|
||||
Use :meth:`~django.db.models.query.QuerySet.defer()` and
|
||||
:meth:`~django.db.models.query.QuerySet.only()` if there are database columns
|
||||
you 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 separate query, making this a pessimization if you use it inappropriately.
|
||||
|
||||
|
|
|
@ -346,7 +346,7 @@ This is roughly equivalent to::
|
|||
|
||||
Note, however, that the first of these will raise ``IndexError`` while the
|
||||
second will raise ``DoesNotExist`` if no objects match the given criteria. See
|
||||
:meth:`~django.db.models.QuerySet.get` for more details.
|
||||
:meth:`~django.db.models.query.QuerySet.get` for more details.
|
||||
|
||||
.. _field-lookups-intro:
|
||||
|
||||
|
|
|
@ -124,8 +124,8 @@ Fields may also be left out::
|
|||
>>> people = Person.objects.raw('SELECT id, first_name FROM myapp_person')
|
||||
|
||||
The ``Person`` objects returned by this query will be deferred model instances
|
||||
(see :meth:`~django.db.models.QuerySet.defer()`). This means that the fields
|
||||
that are omitted from the query will be loaded on demand. For example::
|
||||
(see :meth:`~django.db.models.query.QuerySet.defer()`). This means that the
|
||||
fields 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'):
|
||||
... print p.first_name, # This will be retrieved by the original query
|
||||
|
|
|
@ -21,9 +21,10 @@ At the highest level, serializing data is a very simple operation::
|
|||
data = serializers.serialize("xml", SomeModel.objects.all())
|
||||
|
||||
The arguments to the ``serialize`` function are the format to serialize the data
|
||||
to (see `Serialization formats`_) and a :class:`~django.db.models.QuerySet` to
|
||||
serialize. (Actually, the second argument can be any iterator that yields Django
|
||||
objects, but it'll almost always be a QuerySet).
|
||||
to (see `Serialization formats`_) and a
|
||||
:class:`~django.db.models.query.QuerySet` to serialize. (Actually, the second
|
||||
argument can be any iterator that yields Django objects, but it'll almost
|
||||
always be a QuerySet).
|
||||
|
||||
You can also use a serializer object directly::
|
||||
|
||||
|
|
Loading…
Reference in New Issue