Hey Tom,
Overriding Aggregate.as_sql() to branch on connection.features to build the
FILTER clause shouldn't be an issue.
I think you could rely on super().as_sql(..., filter=filter_sql) extra
parameter when the
connection supports the FILTER statement and fallback to self.clone(),
clone.source
Hey Simon,
Thanks for your reply, I actually agree after thinking about it. Adding a
filter/exclude method and getting it to work correctly in the way people
would expect is be pretty complex. Adding an argument that takes a Q object
would suffice for now at least.
I'm happy to implement this, but
Hello Tom,
Thanks for working on adding filter support to aggregate. I think adding
support for the SQL:2003 features on all aggregates by emulating it on
backends that don't support it using CASE makes a lot of sense[0].
As I've mentioned on your PR this is syntactic sugar I've been missing from
Hi Tom,
I really like the look of Count('emails').filter(unread=False) in the
annotate call.
Ian
On 12/04/17 21:35, Tom Forbes wrote:
> Hello,
> At the Djangocon sprints I wanted to add support for a postgres specific
> syntax for filtering aggregations, which is quite simple: MAX(something)
> F
Hello,
At the Djangocon sprints I wanted to add support for a postgres specific
syntax for filtering aggregations, which is quite simple: MAX(something)
FILTER (WHERE x=1).
During this the sprints I was told that it would be good to support this
for all databases, and it can be done using the CASE
