Aggregation settings are available for some items that can't be aggregated. This is confusing.

For instance, it's possible to use a computed property of an entity as a field value. It can't be aggregated (since that happens in SQL), but the aggregation settings are still there. The settings should be disabled for such fields. There should probably be a value for the field passed via hook_views_data() that disables aggregation settings for such fields.

Also, there there are aggregation settings for filters and sorts, which is strange. Does it make sense to filter on grouped values? Would a filter be applied before an AVG()? If the filtering happens first, the aggregation is irrelevant and the settings should be removed. If aggregation is relevant for some filters, but not others, the options should appear only for the relevant ones.

Files: 
CommentFileSizeAuthor
#6 views_disable_incorrect_aggregation-1881716-6.patch2.06 KBDanZ
PASSED: [[SimpleTest]]: [MySQL] 1,603 pass(es).
[ View ]
#3 3sh1xs.jpg25.33 KBdawehner
#2 views_disable_incorrect_aggregation-1881716-2.patch1.71 KBDanZ
PASSED: [[SimpleTest]]: [MySQL] 1,603 pass(es).
[ View ]

Comments

dawehner’s picture

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.

DanZ’s picture

Status:Active» Needs review
StatusFileSize
new1.71 KB
PASSED: [[SimpleTest]]: [MySQL] 1,603 pass(es).
[ View ]

That does look like a good fix, and appears to work correctly. It's surprising that it isn't already being used much.

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.

Here's a first pass at a patch to play with. It turns off aggregation for all sort handlers, all filter handlers and the math field handler. It removes the "Aggregation settings" link for each of these, which is a big improvement. It probably ought to turn it off for other fields, too.

Questions remaining:

What other field handlers should have this turned off?

Do any filter handlers need this turned back on?

Do any sort handlers need this turned back on?

Will this break any other modules?

Would this cause issues for existing Views with (meaningless) aggregation settings? Would there be a need to clean the settings from the DB?

dawehner’s picture

StatusFileSize
new25.33 KB

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.

3sh1xs.jpg

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

DanZ’s picture

Status:Needs review» Needs work

Understandable. The above patch it just to play with, and that was the fast way to make it. Aggregation should be turned off by default in future versions, though (Drupal 8?).

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

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

  • Math
  • Serialized
dawehner’s picture

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.

DanZ’s picture

StatusFileSize
new2.06 KB
PASSED: [[SimpleTest]]: [MySQL] 1,603 pass(es).
[ View ]

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.

A solution is to add a definition field. This patch lets a module define 'groupable' => FALSE to turn off the aggregation settings link. (Other possibilities for names are 'aggregatable', 'allow group by', and 'allow aggregation'.)

This patch doesn't fix the problem, but at least it allows modules that provide Views data to fix it, and it has no chance of breaking anything.

DanZ’s picture

Status:Needs work» Needs review

Looking at my post above, I think 'allow aggregation' is the best, even though it's the longest.

dawehner’s picture

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.

DanZ’s picture

Well, I can't think of a reason in which a certain class can groupby but a certain field using this class can't?

Entities. Properties from schema fields are groupable. Computed properties are not.

dawehner’s picture

Oh now I totally agree, thank you!.

DanZ’s picture

Some questions about filters. I don't know much about SQL yet.

Filters that use WHERE clauses can't use numeric aggregation, like SUM() or AVG(), right? WHERE clauses only work on actual schema fields, not formulas. These filters only work on plain DB fields, right?

Filters that use HAVING clauses can use numeric aggregation, right? These filters choose result records after the math is done.

What exactly does GROUP BY mean for a filter, anyway? Shouldn't grouping be defined only in field handlers?

Is there any need to differentiate between having GROUP BY and numeric aggregation? Is COUNT aggregation any different? If some are allowed and some not, does it have to be handled by overriding views_handler::groupby_form()?

merlinofchaos’s picture

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.

anrikun’s picture

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.

anrikun’s picture

Issue summary:View changes

Fixed broken sentence.