#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
-------------------------------------+-------------------------------------
Changes (by carljm):

 * needs_docs:  0 => 1
 * needs_tests:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the patch! The feature idea generally makes sense to me -
 taking something that currently results in an error and making it instead
 return sane results. Tentatively accepting based on that. Some thoughts:

 1. We need to check what the other core backends currently do with this
 query. If there are backends in which that query is currently an error,
 but this patch would change their results, that might be a problem.

 2. If I understand the Postgres docs correctly, your proposed subquery SQL
 results in an undefined/unpredictable selection of which actual row is
 chosen of each group where the `DISTINCT ON` query returns the same value.
 I guess if this is a problem, the answer is "make your `ORDER BY` match
 the `DISTINCT ON`", but it seems like a non-obvious subtlety that might
 bite people.

 If nobody else sees any blockers that I'm missing, the things that would
 still be needed here are:

 a) Add a test demonstrating the new behavior.
 b) Add/update the documentation as needed (I think this is a behavior that
 ought to be mentioned in the docs somewhere).
 c) Turn it into a pull request so the CI runs on it and we can see if it
 breaks any existing tests.

 Once those are done there may be some comments on code style or
 implementation choices. The POC code seems clear enough, but I'd defer to
 others who know the ORM better on whether it's actually implemented at the
 right level / in the right place.

--
Ticket URL: <https://code.djangoproject.com/ticket/24218#comment:2>
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.57bf7e522062ae207414e435e6421b2b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to