#10060: Multiple table annotation failure
---------------------------------+------------------------------------
Reporter: svsharma@… | Owner:
Type: Bug | Status: new
Component: ORM aggregation | Version: master
Severity: Normal | 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 akaariai):
This is somewhat hard problem. We could do automatic subquery pushdown for
aggregates - it isn't exactly easy but most of the pieces are already
there. I am not sure how well such queries will perform. Although that
isn't perhaps too important. If the results aren't correct speed doesn't
matter...
I think a good start to this would be documentation + detecting the
problematic situations and throwing an error in those cases. Basically if
we have two multijoins in the query (from filtering, aggregation or
something else) and aggregation is used then the query is likely wrong.
However this condition is a little too restrictive - something like:
{{{
qs.filter(translations__lang='fi', translations__name='foo')
}}}
introduces a multijoin to translations, yet the query is safe as
translations.lang is unique. Detecting if we have a unique multijoin is
going to be nasty. So, we need a way to bypass this error checking.
Proposal: aggregates get a new kwarg "inline" - default False. If inline
is False, then multiple multijoins in single query will raise an error. If
it is True, the aggregate is forced to be joined to the query (that is, to
do what aggregates do today). Later on we will likely add another kwarg
"subquery" - defaults again to False. If set to True the aggregate is
forced to subquery (something like in comment:9). We could also add kwarg
"subselect". Later on maybe also "lateral_subquery" and so on.
The proposal allows us to throw an error, yet give users the ability to
force the ORM to generate the queries they are using now. It also allows
for extending the same API if we get subquery aggregate support some day.
I think we need to add the information about multijoins to JoinInfo, and
add the info about used joins to aggregates when they are added to the
query. Then at compiler stage, check for all inline=False aggregates if
there are multijoins in the query not used by the aggregate itself. If so,
throw an error. Changes should be needed at query.setup_joins(),
compiler.get_from_clause() and then a way to annotate the used joins into
the aggregate (this should not be too hard).
--
Ticket URL: <https://code.djangoproject.com/ticket/10060#comment:40>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit https://groups.google.com/groups/opt_out.
