Aggregation settings available for items that don't aggregate

Actually it is easy, every handler can specify for itself, whether it support groupby/aggregation or not.

class ... {
  function use_group_by() {
    return TRUE;
  }
}

It's excluded by default for all areas/relationships though for other places we might should do it as well.
The global math field is one of those examples.

When we got this in, we decided to figure that out with time, though no-one had the mood to do it.
Thanks for taking it over.

I'm not sure that aggregation is meaningful to any of the filter or sort handlers. If it isn't, then it should be turned off at the top-most available level: views_handler_filter and views_handler_sort.

Well, I don't want to break any views site, so changing the default is SO much a no-go.

Please only do it on the handlers you know, which does not work.

Aggregation should be turned off by default in future versions, though (Drupal 8?).

Most handler might support aggregation so this would make the DX really worse for simple handlers.

For which sort and filter handlers does aggregation actually mean something? As far as I know, the answer is "none".

An example of filter: Get me all users with more then 5 nodes. An example of sort: Get me all users with the amount of nodes DESCENDING.

For which field handlers is aggregation invalid? So far, I've found:

Everything which has it's logic in the render function. I guess looking for function pre_render() is a really good indicator.

The problem with not touching the top-level classes is that many view definitions out there use those top-level classes. Modules that use those classes can't get rid of the aggregation settings without extending the class themselves.

Well, I can't think of a reason in which a certain class can groupby but a certain field using this class can't? The actual behaviour is always driven by the PHP class, so that's the place where you know whether something can be aggregated or not.

Oh now I totally agree, thank you!.

If they're computed they won't be using the basic handlers. They'll need a specific entity-derived handler which probably should default to no aggregation.

I think that how aggregation currently works is a real mess and adding a simple GROUP BY clause to a query (like it was possible in Views 2) is impossible.
Once you turn aggregation on, it adds a bunch of fields to the GROUP BY clause, most of them being unwanted.
At least we should allow user to disable aggregation on a per field/filter/etc. basis by adding a new option to "Aggregation type".

Edit: all right, I guess it's because we want to stick to the SQL Standard that requires that each field in SELECT has to be present in the GROUPBY clause.

Fixed broken sentence.

The 6 year old patch in #6 to views_handler_field_math.inc and handlers.inc does not apply to the latest views 7.x-3.x-dev.

Checking patch handlers/views_handler_field_math.inc...
error: while searching for:
  }

  function query() { }
}

error: patch failed: handlers/views_handler_field_math.inc:81
error: handlers/views_handler_field_math.inc: patch does not apply

Checking patch includes/handlers.inc...
error: while searching for:
 * Prepare a handler's data by checking defaults and such.
 */
function _views_prepare_handler($definition, $data, $field, $type) {
  foreach (array('group', 'title', 'title short', 'help', 'real field') as $key) {
    if (!isset($definition[$key])) {
      // First check the field level
      if (!empty($data[$field][$key])) {

error: patch failed: includes/handlers.inc:71
error: includes/handlers.inc: patch does not apply

@Chris Matthews, Rerolled Aggregation settings patch as per current branch, This patch will be applied smoothly in 7.x-3.x-dev. hope this will helps you!..

Thanks