2009-01-15 19:06:34 +08:00
|
|
|
"""
|
|
|
|
Classes to represent the definitions of aggregate functions.
|
|
|
|
"""
|
Refactored qs.add_q() and utils/tree.py
The sql/query.py add_q method did a lot of where/having tree hacking to
get complex queries to work correctly. The logic was refactored so that
it should be simpler to understand. The new logic should also produce
leaner WHERE conditions.
The changes cascade somewhat, as some other parts of Django (like
add_filter() and WhereNode) expect boolean trees in certain format or
they fail to work. So to fix the add_q() one must fix utils/tree.py,
some things in add_filter(), WhereNode and so on.
This commit also fixed add_filter to see negate clauses up the path.
A query like .exclude(Q(reversefk__in=a_list)) didn't work similarly to
.filter(~Q(reversefk__in=a_list)). The reason for this is that only
the immediate parent negate clauses were seen by add_filter, and thus a
tree like AND: (NOT AND: (AND: condition)) will not be handled
correctly, as there is one intermediary AND node in the tree. The
example tree is generated by .exclude(~Q(reversefk__in=a_list)).
Still, aggregation lost connectors in OR cases, and F() objects and
aggregates in same filter clause caused GROUP BY problems on some
databases.
Fixed #17600, fixed #13198, fixed #17025, fixed #17000, fixed #11293.
2012-05-25 05:27:24 +08:00
|
|
|
from django.db.models.constants import LOOKUP_SEP
|
|
|
|
|
2013-07-08 08:39:54 +08:00
|
|
|
|
Refactored qs.add_q() and utils/tree.py
The sql/query.py add_q method did a lot of where/having tree hacking to
get complex queries to work correctly. The logic was refactored so that
it should be simpler to understand. The new logic should also produce
leaner WHERE conditions.
The changes cascade somewhat, as some other parts of Django (like
add_filter() and WhereNode) expect boolean trees in certain format or
they fail to work. So to fix the add_q() one must fix utils/tree.py,
some things in add_filter(), WhereNode and so on.
This commit also fixed add_filter to see negate clauses up the path.
A query like .exclude(Q(reversefk__in=a_list)) didn't work similarly to
.filter(~Q(reversefk__in=a_list)). The reason for this is that only
the immediate parent negate clauses were seen by add_filter, and thus a
tree like AND: (NOT AND: (AND: condition)) will not be handled
correctly, as there is one intermediary AND node in the tree. The
example tree is generated by .exclude(~Q(reversefk__in=a_list)).
Still, aggregation lost connectors in OR cases, and F() objects and
aggregates in same filter clause caused GROUP BY problems on some
databases.
Fixed #17600, fixed #13198, fixed #17025, fixed #17000, fixed #11293.
2012-05-25 05:27:24 +08:00
|
|
|
def refs_aggregate(lookup_parts, aggregates):
|
|
|
|
"""
|
|
|
|
A little helper method to check if the lookup_parts contains references
|
|
|
|
to the given aggregates set. Because the LOOKUP_SEP is contained in the
|
|
|
|
default annotation names we must check each prefix of the lookup_parts
|
|
|
|
for match.
|
|
|
|
"""
|
|
|
|
for i in range(len(lookup_parts) + 1):
|
|
|
|
if LOOKUP_SEP.join(lookup_parts[0:i]) in aggregates:
|
|
|
|
return True
|
|
|
|
return False
|
2009-01-15 19:06:34 +08:00
|
|
|
|
2013-07-08 08:39:54 +08:00
|
|
|
|
2009-01-15 19:06:34 +08:00
|
|
|
class Aggregate(object):
|
|
|
|
"""
|
|
|
|
Default Aggregate definition.
|
|
|
|
"""
|
|
|
|
def __init__(self, lookup, **extra):
|
|
|
|
"""Instantiate a new aggregate.
|
|
|
|
|
|
|
|
* lookup is the field on which the aggregate operates.
|
|
|
|
* extra is a dictionary of additional data to provide for the
|
|
|
|
aggregate definition
|
|
|
|
|
|
|
|
Also utilizes the class variables:
|
|
|
|
* name, the identifier for this aggregate function.
|
|
|
|
"""
|
|
|
|
self.lookup = lookup
|
|
|
|
self.extra = extra
|
|
|
|
|
|
|
|
def _default_alias(self):
|
|
|
|
return '%s__%s' % (self.lookup, self.name.lower())
|
|
|
|
default_alias = property(_default_alias)
|
|
|
|
|
|
|
|
def add_to_query(self, query, alias, col, source, is_summary):
|
|
|
|
"""Add the aggregate to the nominated query.
|
|
|
|
|
|
|
|
This method is used to convert the generic Aggregate definition into a
|
|
|
|
backend-specific definition.
|
|
|
|
|
|
|
|
* query is the backend-specific query instance to which the aggregate
|
|
|
|
is to be added.
|
|
|
|
* col is a column reference describing the subject field
|
|
|
|
of the aggregate. It can be an alias, or a tuple describing
|
|
|
|
a table and column name.
|
|
|
|
* source is the underlying field or aggregate definition for
|
|
|
|
the column reference. If the aggregate is not an ordinal or
|
|
|
|
computed type, this reference is used to determine the coerced
|
|
|
|
output type of the aggregate.
|
|
|
|
* is_summary is a boolean that is set True if the aggregate is a
|
|
|
|
summary value rather than an annotation.
|
|
|
|
"""
|
2009-02-02 20:03:31 +08:00
|
|
|
klass = getattr(query.aggregates_module, self.name)
|
|
|
|
aggregate = klass(col, source=source, is_summary=is_summary, **self.extra)
|
2009-02-23 22:47:59 +08:00
|
|
|
query.aggregates[alias] = aggregate
|
2009-01-15 19:06:34 +08:00
|
|
|
|
2013-07-08 08:39:54 +08:00
|
|
|
|
2009-01-15 19:06:34 +08:00
|
|
|
class Avg(Aggregate):
|
|
|
|
name = 'Avg'
|
|
|
|
|
2013-07-08 08:39:54 +08:00
|
|
|
|
2009-01-15 19:06:34 +08:00
|
|
|
class Count(Aggregate):
|
|
|
|
name = 'Count'
|
|
|
|
|
2013-07-08 08:39:54 +08:00
|
|
|
|
2009-01-15 19:06:34 +08:00
|
|
|
class Max(Aggregate):
|
|
|
|
name = 'Max'
|
|
|
|
|
2013-07-08 08:39:54 +08:00
|
|
|
|
2009-01-15 19:06:34 +08:00
|
|
|
class Min(Aggregate):
|
|
|
|
name = 'Min'
|
|
|
|
|
2013-07-08 08:39:54 +08:00
|
|
|
|
2009-01-15 19:06:34 +08:00
|
|
|
class StdDev(Aggregate):
|
|
|
|
name = 'StdDev'
|
|
|
|
|
2013-07-08 08:39:54 +08:00
|
|
|
|
2009-01-15 19:06:34 +08:00
|
|
|
class Sum(Aggregate):
|
|
|
|
name = 'Sum'
|
|
|
|
|
2013-07-08 08:39:54 +08:00
|
|
|
|
2009-01-15 19:06:34 +08:00
|
|
|
class Variance(Aggregate):
|
|
|
|
name = 'Variance'
|