--
Ticket URL: <https://code.djangoproject.com/ticket/18743>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* status: new => closed
* needs_better_patch: => 0
* resolution: => wontfix
* needs_tests: => 0
* needs_docs: => 0
Comment:
As you said, select_for_update on an aggregate wouldn't make any sense.
The correct behaviour here is to silently ignore it and execute the
aggregate. This is similar to what happens in databases that don't support
select_for_update like SQLite
(https://docs.djangoproject.com/en/dev/ref/models/querysets/#select-for-
update).
--
Ticket URL: <https://code.djangoproject.com/ticket/18743#comment:1>
Comment (by Josh Kupershmidt <schmiddy@…>):
I agree with the OP, as I was pretty surprised by Django's behavior here
myself recently when attempting to use select_for_update() in combination
with a Sum() aggregate. I would have liked to see an explicit error in
this case. And I think this kind of confusion may be common, see e.g.
http://stackoverflow.com/questions/18455473/why-cant-i-use-select-for-
update-with-aggregate-functions
I think if we can raise an Exception for unsupported operations such as
in, say:
Passing nowait=True to select_for_update() using database backends that
do not support nowait, such as MySQL, will cause a DatabaseError to be
raised.
Then there is a good case to be made for raising an Exception here.
--
Ticket URL: <https://code.djangoproject.com/ticket/18743#comment:2>