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

docs/intro/tutorial03.txt

@@ -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
+It's a very common idiom to use :meth:`~django.db.models.query.QuerySet.get`
-:exc:`~django.http.Http404` if the object doesn't exist. Django provides a
+and raise :exc:`~django.http.Http404` if the object doesn't exist. Django
-shortcut. Here's the ``detail()`` view, rewritten::
+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
+passes to the module's :meth:`~django.db.models.query.QuerySet.get` function.
-raises :exc:`~django.http.Http404` if the object doesn't exist.
+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.query.QuerySet.filter` instead of
-:meth:`~django.db.models.QuerySet.get`. It raises :exc:`~django.http.Http404` if
+:meth:`~django.db.models.query.QuerySet.get`. It raises
-the list is empty.
+:exc:`~django.http.Http404` if the list is empty.
 
 Write a 404 (page not found) view
 =================================

docs/ref/class-based-views.txt

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

docs/ref/contrib/admin/actions.txt

@@ -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
+    <django.db.models.query.QuerySet.delete>` for efficiency reasons, which
-    important caveat: your model's ``delete()`` method will not be called.
+    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
+    * A :class:`~django.db.models.query.QuerySet` containing the set of
-      selected by the user.
+      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::

docs/ref/contrib/admin/index.txt

@@ -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
+    :meth:`~django.db.models.query.QuerySet.select_related` in retrieving
-    objects on the admin change list page. This can save you a bunch of
+    the list of objects on the admin change list page. This can save you a
-    database queries.
+    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
+    :class:`~django.db.models.query.QuerySet` of all model instances that
-    edited by the admin site. One use case for overriding this method is
+    can be edited by the admin site. One use case for overriding this method
-    to show objects owned by the logged-in user::
+    is to show objects owned by the logged-in user::
 
         class MyModelAdmin(admin.ModelAdmin):
             def queryset(self, request):

docs/ref/contrib/contenttypes.txt

@@ -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
+:meth:`~django.db.models.query.QuerySet.aggregate` method doesn't take them
-account. For now, if you need aggregates on generic relations, you'll need
+into account. For now, if you need aggregates on generic relations, you'll
-to calculate them without using the aggregation API.
+need to calculate them without using the aggregation API.
 
 Generic relations in forms and admin
 ------------------------------------

docs/ref/contrib/gis/db-api.txt

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

docs/ref/models/options.txt

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

docs/ref/models/querysets.txt

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

docs/releases/1.1-beta-1.txt

@@ -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.query.QuerySet.defer` and
-:meth:`~django.db.models.QuerySet.only`.
+:meth:`~django.db.models.query.QuerySet.only`.
 
 New admin features
 ------------------

docs/releases/1.1.txt

@@ -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.query.QuerySet.defer` and
-:meth:`~django.db.models.QuerySet.only`.
+:meth:`~django.db.models.query.QuerySet.only`.
 
 Testing improvements
 --------------------

docs/topics/db/aggregation.txt

@@ -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:
+:meth:`~django.db.models.query.QuerySet.distinct` and the general rule is the
-normally you won't want extra columns playing a part in the result, so clear
+same: normally you won't want extra columns playing a part in the result, so
-out the ordering, or at least make sure it's restricted only to those fields
+clear out the ordering, or at least make sure it's restricted only to those
-you also select in a ``values()`` call.
+fields you also select in a ``values()`` call.
 
 .. note::
     You might reasonably ask why Django doesn't remove the extraneous columns

docs/topics/db/optimization.txt

@@ -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
+Use :meth:`~django.db.models.query.QuerySet.defer()` and
-:meth:`~django.db.models.QuerySet.only()` if there are database columns you
+:meth:`~django.db.models.query.QuerySet.only()` if there are database columns
-know that you won't need (or won't need in most cases) to avoid loading
+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.
 

docs/topics/db/queries.txt

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

docs/topics/db/sql.txt

@@ -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
+(see :meth:`~django.db.models.query.QuerySet.defer()`). This means that the
-that are omitted from the query will be loaded on demand. For example::
+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

docs/topics/serialization.txt

@@ -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
+to (see `Serialization formats`_) and a
-serialize. (Actually, the second argument can be any iterator that yields Django
+:class:`~django.db.models.query.QuerySet` to serialize. (Actually, the second
-objects, but it'll almost always be a QuerySet).
+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::