#33767: Ordering by F-expression resolving to a number returns wrong results
-------------------------------------+-------------------------------------
Reporter: Florian Apolloner | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Florian Apolloner):
> Could we possibly error out at resolving time instead of adding logic to
the compiler given ordering by a constant value is a noop?
Probably.
> Given it's a noop we could also simply drop the ordering without raising
an error.
I'd be rather strongly against that. Given that it is a noop, it is
certainly not what the user intended to write, so maybe an error is the
best idea. The next question that comes to mind here is: Do we want to
support ordering like this `User.objects.order_by(Value(1).desc())` --
this currently works and the intent seems rather clear to me (ie sort by
the first column). It at least somewhat works, but starts to break down
when you add `nulls_first=True` there because all of a sudden we are
generating `ORDER BY 1 IS NULL, 1 DESC` on MySQL which is wrong again (See
also #33768).
We probably should merge those two tickets together and consider them as
one, what do you think?
--
Ticket URL: <https://code.djangoproject.com/ticket/33767#comment:5>
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/010701813842f0d9-82f5b6b1-090c-4c2d-81ac-59e1d550b5cd-000000%40eu-central-1.amazonses.com.
