#24218: Use sub-query in ORM when distinct and order_by columns do not match
-------------------------------------+-------------------------------------
     Reporter:  miki725              |                    Owner:  nobody
         Type:  New feature          |                   Status:  new
    Component:  Database layer       |                  Version:  master
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:
     Keywords:  subquery distinct    |             Triage Stage:  Accepted
  order_by                           |
    Has patch:  1                    |      Needs documentation:  1
  Needs tests:  1                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by carljm):

 @miki725 - In a case like yours, I've generally just done `.distinct()`
 instead of `.distinct('id')`. Since you're only selecting columns from
 foo, that should give the same results, and it makes Postgres happy with
 any `ORDER BY` clause you like, with no need for a subquery. So I'm not
 sure that your particular case actually offers a use case for this feature
 - in this case our support for `DISTINCT ON` is actually an "attractive
 nuisance."

 @akaariai - that API doesn't feel quite right to me. `order_by()` in every
 other case determines the ordering of the returned results. Just because
 in this case we are also applying a SQL `ORDER BY` clause in the subquery
 (an implementation detail) doesn't mean that overloading `order_by()` is
 the right API for it. For addressing this particular use case, I think a
 more intuitive API would be to introduce an ordering argument to
 `.distinct()` to allow customization of the ordering used to pick the
 distinct row. Of course, that's a less general API - but I think we would
 need a more thorough list of the cases where subqueries are needed in
 order to see what a generic subqueries API should look like (e.g. are you
 intending to limit this API to cases where the outer query is simply a
 `SELECT *` from the subquery?). It feels to me that a generic subqueries
 API should involve passing one queryset to another, or wrapping one in
 another, much like the current case where passing a queryset to an `__in`
 filter results in a subquery.

--
Ticket URL: <https://code.djangoproject.com/ticket/24218#comment:8>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.d6333e10ae45d95b57530680bd115fb3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to