#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 django-updates+unsubscr...@googlegroups.com.
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.
