Django

Code

Show
Ignore:
Timestamp:
04/24/08 11:07:07 (9 months ago)
Author:
mtredinnick
Message:

queryset-refactor: Changed the way order_by() and distinct() interact.

When using "select distinct" all ordering columns must be part of the output
(select) columns. We were previously just throwing away ordering columns that
weren't included, but there are some cases where they are needed and it's
difficult to add them in manually. So now the default behaviour is to append
any missing columns.

This can affect the output of distinct() if complicated order_by() constructs
are used, so the documentation has been updated with an explanation of what's
going on there.

Fixed #7070.

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • django/branches/queryset-refactor/docs/db-api.txt

    r7453 r7455  
    511511...since the ``Blog`` model has no default ordering specified. 
    512512 
     513Be cautious when ordering by fields in related models if you are also using 
     514``distinct()``. See the note in the `distinct()`_ section for an explanation 
     515of how related model ordering can change the expected results. 
     516 
    513517It is permissible to specify a multi-valued field to order the results by (for 
    514518example, a ``ManyToMany`` field). Normally this won't be a sensible thing to 
    …… 
    560564By default, a ``QuerySet`` will not eliminate duplicate rows. In practice, this 
    561565is rarely a problem, because simple queries such as ``Blog.objects.all()`` 
    562 don't introduce the possibility of duplicate result rows. 
    563  
    564 However, if your query spans multiple tables, it's possible to get duplicate 
    565 results when a ``QuerySet`` is evaluated. That's when you'd use ``distinct()``. 
     566don't introduce the possibility of duplicate result rows. However, if your 
     567query spans multiple tables, it's possible to get duplicate results when a 
     568``QuerySet`` is evaluated. That's when you'd use ``distinct()``. 
     569 
     570.. note:: 
     571    Any fields used in an ``order_by()`` call are included in the SQL 
     572    ``SELECT`` columns. This can sometimes lead to unexpected results when 
     573    used in conjuntion with ``distinct()``. If you order by fields from a 
     574    related model, those fields will be added to the selected columns and they 
     575    may make otherwise duplicate rows appear to be distinct. Since the extra 
     576    columns don't appear in the returned results (they are only there to 
     577    support ordering), it sometimes looks like non-distinct results are being 
     578    returned. 
     579 
     580    Similarly, if you use a ``values()`` query to restrict the columns 
     581    selected, the columns used in any ``order_by()`` (or default model 
     582    ordering) will still be involved and may affect uniqueness of the results. 
     583 
     584    The moral here is that if you are using ``distinct()`` be careful about 
     585    ordering by related models. Similarly, when using ``distinct()`` and 
     586    ``values()`` together, be careful when ordering by fields not in the 
     587    ``values()`` call. 
    566588 
    567589``values(*fields)`` 
    …… 
    628650        >>> Entry.objects.values('blog_id') 
    629651        [{'blog_id': 1}, ...] 
     652    * When using ``values()`` together with ``distinct()``, be aware that 
     653      ordering can affect the results. See the note in the `distinct()`_ 
     654      section, above, for details. 
    630655 
    631656**New in Django development version:** Previously, it was not possible to pass 
    …… 
    842867call, since they are conflicting options. 
    843868 
    844 ``extra(select=None, where=None, params=None, tables=None, order_by=None, 
    845 select_params=None)`` 
     869``extra(select=None, where=None, params=None, tables=None, order_by=None, select_params=None)`` 
    846870~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
    847871