I don't know if this is a bug, so I submit it as support request.
My handler does aggregation by adding field with "aggregate" = TRUE property (and NOT invoking add_groupby()). This breaks count queries, because query() method only checks if there are GROUP BY clauses by checking $this->groupby. It doesn't check if there are aggregate fields.
It doesn't find $this->groupby, and tries to optimize the query leaving only base field (and counting it).
I.e. it's the following code block:

/**
     * An optimized count query includes just the base field instead of all the fields.
     * Determine of this query qualifies by checking for a groupby or distinct.
     */
    $fields_array = $this->fields;
    if ($get_count && !$this->groupby) {
      foreach ($fields_array as $field) {
        if (!empty($field['distinct'])) {
          $get_count_optimized = FALSE;
          break;
        }
      }
    }
    else {
      $get_count_optimized = FALSE;
    }
    if (!isset($get_count_optimized)) {
      $get_count_optimized = TRUE;
    }

First question: shouldn't it also check presence of "aggregate" fields and set $get_count_optimized = FALSE too ?
Second question: is it a bug of Views that query() method gets $this->groupby empty when there are "aggregate" fields ?

Other than paging, the view is working fine. So this provides third question: should handlers also invoke add_groupby() when adding "aggregate" fields ? If that is the case it's not convenient because if handler doesn't run last, it can't know other fields participating in the query so it can't cast GROUP BY on them.
I know that I can manually feed proper count query by using hook_views_pre_execute() but that's inconvenient too and ties your code to specific views.

Comments

dawehner’s picture

This kind of code is just part of views3 which has real groupby support. Perhaps some parts of the query building could be backported. Views2 does not support groupby even from api level from my perspective.

crea’s picture

Well, in my experience GROUP BY in Views 2 generally works on the API level. Random bugs happen here and there, just like this one.

Letharion’s picture

Assigned: Unassigned » esmerel
dawehner’s picture

@crea

The query code was changed/fixed in views3 to support groupby 100%. So even if you need the api level you might have to switch to views3.

crea’s picture

Sure, I will do that when it will be as polished as views 2 and will allow smooth upgrade (meaning, all modules continue working). Until then, it's not an option.

dawehner’s picture

Already tryed it out? Then please provide informations which doesn't work at the moment.

crea’s picture

Status: Active » Fixed

I am too busy for testing at the moment. I have several sites with 2.x and I am adept of "Don't fix it if it's not broken" theory so I'm not willing to try 3.x and get new portion of bugs in exchange for this bugfix.
This bug is already workarounded in Privatemsg Views module, and the question is could we have it fixed properly in 2.x. I guess the answer is "no".
Next branch of Privatemsg Views will be based on Views 3.x thats for sure, I hope it will work there...

merlinofchaos’s picture

Version: 6.x-2.11 » 6.x-2.x-dev
Category: support » bug
Status: Fixed » Active

Hmm. Thinking about this, setting $aggregate = TRUE should work for the count queyr, so I consider this a bug and should be fixed.

iamjon’s picture

Assigned: esmerel » Unassigned
Category: bug » task

Marking this as an unassigned task based on the last comment.

mustanggb’s picture

Status: Active » Closed (won't fix)