#26430: Coalesce in Aggregations ignored when EmptyResultSet returned
-------------------------------------+-------------------------------------
     Reporter:  ryanprater           |                    Owner:  nobody
         Type:  Bug                  |                   Status:  new
    Component:  Database layer       |                  Version:  1.9
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:
     Keywords:  aggregation          |             Triage Stage:
  coalesce in queryset               |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Changes (by jarshwah):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 I do agree that this is a bug, but I don't think the correct fix is to
 detect specific expressions and apply custom logic for each one. Simon
 mentioned nested expressions which would be very difficult to resolve the
 correct behaviour for.

 For what it's worth, a `Count` will also show `None` in an EmptyResultSet
 even though its converters should coerce `None` to `0`. The reason it
 doesn't is because the expressions and aggregates aren't actually used.
 Everything is Noned.

 If I was writing this from scratch I'd raise an error on receiving an
 EmptyResultSet. An empty list in a filter clause seems like broken
 behaviour. We can't do that though, because it's backwards incompatible,
 and there's probably valid use cases for this behaviour now.

 A possible fix would be to implement something like `on_empty_result` for
 Expressions, to let each subclass decide what it should return if it's not
 executed. It would have to recursively call this method, and then decide
 which children should be allowed to propagate their values. But honestly,
 this seems like a lot of work and complexity for very little gain.

 Short of documentation changes or a deprecation, I'd be tempted to wontfix
 this. I'm certainly open to ideas I haven't considered though.

--
Ticket URL: <https://code.djangoproject.com/ticket/26430#comment:1>
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.531db085740a40f3f01c91d69bcde4a0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to