#31150: Subquery annotations are omitted in group by query section if multiple
annotation are declared
-------------------------------------+-------------------------------------
     Reporter:  Johannes Hoppe       |                    Owner:  nobody
         Type:  Bug                  |                   Status:  new
    Component:  Database layer       |                  Version:  3.0
  (models, ORM)                      |
     Severity:  Release blocker      |               Resolution:
     Keywords:                       |             Triage Stage:  Accepted
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by Simon Charette):

 Thanks for the extra details, I think I have a better picture of what's
 happening here.

 In the cases where an outer query spawns a multi-valued relationship and
 the subquery references one of these multi-valued relationship we must
 keep grouping by the subquery.

 In your original reports the `INNER JOIN "camps_bookingoption" T4` joins
 spawns multiple rows for the same `camps.Offer` and then your subquery
 filter against `(T4."position")` which

 In ORM terms that means we must keep returning `self` in
 `Subquery.get_group_by_cols` when any of our `OuterRef` include a `__`
 which could point to a multi-valued relationship.

 We could go a bit further and only disable the optimization if any of the
 outer-ref in the `__` chain is multi-valued by relying on `getattr(rel,
 'many_to_many', True)` introspection but in all cases that means adding a
 way to ''taint'' `Col` instances with whether or not they are/could be
 multi-valued so `get_group_by_cols` can `return self` if any of
 `get_external_cols` is multi-valued

 I could see this tainting as being useful to warn about #10060 in the
 future since the logic could be based on this column or alias tainting.

 I'm happy to submit a patch or discuss any alternatives but it feels like
 the above solution solves the reported problem while maintaining the
 optimization for most of the cases.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/31150#comment:10>
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/067.040b1b7ed8df049e944e3a86db8d65ec%40djangoproject.com.

Reply via email to