Problem/Motivation
When working on aggregated Views for Commerce Reports, I noticed some weird behaviors with our Price field. Output would be fine when the normal "group", but once I changed to SUM or AVG it would render as a numeric/integer field and lose all formatting. I did some digging and found out the Display plugin overrides the handler based on information in \Drupal\views\Plugin\views\query\Sql::getAggregationInfo.
The problem is that \Drupal\views\Plugin\views\field\FieldPluginBase::addAdditionalFields applies that grouping to each additional field. In the case of an entity field that means it tries to SUM/AVG the bundle, entity ID, or any other field columns. In our case, it kills the currency code.
Upon reviewing the code I see:
$group_params = [];
if ($this->options['group_type'] != 'group') {
$group_params = [
'function' => $this->options['group_type'],
];
}
if (!empty($fields) && is_array($fields)) {
....
$params += $group_params;
$this->aliases[$identifier] = $this->query->addField($table_alias, $info['field'], NULL, $params);
As you can see in this screenshot, the langcode, bundle, and currency_code become "0" since it performs SUM() on a string.

Proposed resolution
Views should not apply the group/aggregate function on all additional fields.
I don't know if this is considered BC or not. None of the additional fields are rendered or ever managed (or ever had valid data.)
Remaining tasks
Create patch
Discuss if BC
Hopefully fix?
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 2975149-3.patch | 1.24 KB | mglaman |
| #2 | aggregate-bundle-sum.png | 123 KB | mglaman |
Issue fork drupal-2975149
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
mglamanAdding screenshot.
Comment #3
mglamanProposed fix.
Comment #4
lendudeAs far as I know, all this grouping is done to make valid SQL. MySQL doesn't care, but apparently PostGres does. So I queued for postgres too, to see if that currently breaks anything there.
Since the fields get added to the query, SQL wants a grouping, so if I'm reading this right, for any additional fields we currently assume the same grouping as the base field. It's a guess, sure, but it's a fair guess.
Again, if I'm reading this right, the current proposed fix completely removes the grouping, which, I think, would lead to an invalid SQL query.
Comment #5
mglamanLendude, thanks for the reply.
This was the output of our SQL query from Views. Hopefully PostGres passes
Comment #6
lendudeGROUP BY commerce_order_report_created, commerce_order_report__mail_delta, commerce_order_report__mail_langcode, commerce_order_report__mail_bundle, commerce_order_report__mail_mail_value_1, commerce_order_report__amount_delta, commerce_order_report__amount_langcode, commerce_order_report__amount_bundle, commerce_order_report__amount_amount_number_1, commerce_order_report__amount_amount_currency_code, commerce_order_report_created_monthAh good, so the additional fields still get added to the 'group by' clause, which was my main concern.
So now it comes down to a lack of options to steer the grouping type, I guess. There is no way, currently, to specify the type of grouping for 'additional' fields. So in the current situation, the guess is that it should be the same as the base field and with the fix the guess is that it should not use a grouping type.
A guess is still a guess, and we can (nay, we will) guess wrong.
But they are available as tokens right? So they can be printed? If that is so, I think we do need to consider BC.
The only BC way forward that springs to mind is adding an option to the grouping settings that allow you to steer this: 'Use grouping type on additional fields', or something along those lines. Any other ideas?
Comment #7
mglamanI am not sure, I could check.
I suppose "Use grouping type on additional fields" as a default makes sense. Then it's just a document step in Commerce Reports "select SUM or AVG, and uncheck this checkbox"
I'd love to have the same options from the EntityField handler, but Views overrides it to be a generic Numeric handler. Where you can specify additional fields to include (whereas with Numeric I think they're all automatically included?)
This is the only "quick" fix I can think of since there is no way to control the field handler when it is aggregated, from an implementation standpoint.
Comment #17
smustgrave commentedThis issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.
Think next step would be adding a test case to show this issue.
Comment #19
pebosi commentedCould you add a re-rolled patch for 10.1 and 10.2 ?
Comment #21
ankithashettyPatch in #3 still gets applied on 10.1, 10.2 and 11.x.