Problem/Motivation
#2735997: Decimal separator and precision settings unavailable when aggregating decimal fields introduced a major regression in a minor release where views aggregation output was broken for any non string or numeric field. We have some tests around aggregation output, e.g QueryGroupByTest but many of these are either a) on the id or name field, or b) don't test the actual views output, rather testing the result rows themselves which don't surface the bug.
Proposed resolution
Add test coverage
Remaining tasks
Decide how much test coverage we should add
Do it
Issue fork drupal-3517853
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:
- 3517853-regression-count-aggregation
changes, plain diff MR !11761
Comments
Comment #3
acbramley commentedIt seems like string based fields work fine (tested the output of COUNT on the name and that works without the fixed) so perhaps it's a numeric field issue?
Comment #4
acbramley commentedThat breaks testFieldAggregationSettings again, gonna have to dig further into this
Comment #5
acbramley commentedTest is correctly failing now:
I'm debugging how views renders this stuff 🤯
When we get to StylePluginBase::elementPreRenderRow we have the correct count value in
$data['#row']. What's happening is that value of4is being passed to the timestamp formatter which results in the Jan 1 1970 date (unix epoch)Before #2735997: Decimal separator and precision settings unavailable when aggregating decimal fields, the field handler was being overridden to numeric, therefore $field in that preRender was the NumericField plugin, not EntityField.
Comment #6
acbramley commentedConfirmed this isn't just an issue with COUNT either, SUM etc have the same behaviour. I'm starting to think we do need to revert here and come up with a proper fix. The field handlers should be overridden because we don't want to go through the EntityField plugin when outputting aggregation data.
Comment #7
acbramley commentedComment #8
acbramley commentedComment #9
acbramley commentedI also confirmed this issue with other field types such as Link
Comment #10
elc commentedThe contrib module Fraction is also affected by this, with aggregation values disappearing.
In Core 10.4.5 the SUM output used Drupal\views\Plugin\views\field\NumericField, but in 10.4.6 it turned up in a Drupal\fraction\Plugin\views\field\FractionField using
Drupal\fraction\Fraction\FractionItem::setValue(['numerator' => NN.NN]). setValue wasn't expecting such a value (normally it would be presented withFractionItem::setValue(['decimal' => NN.NN])or ['numerator' => X, 'denominator' => Y]) resulting in the value always being empty as per the FractionItem::isEmpty().Using both AUM & AVG in the same view ends up with one affecting the other, where in 10.4.5 that did not happen. I haven't figured out where that is happening.
Comment #11
anybodyI can also confirm this issue using commerce_reports. This is a major problem as these reports are essential for the stores.
Edit: Actually this is the case for us: #3517926: Upgrading from 10.4.5 to 10.4.6 removes views format plural on Content ID field
Comment #13
joelpittetSince @catch reverted the other issue, I caught up the branch to see if it now passes as I assume is expected now.
Comment #14
acbramley commentedRescoping this issue for improved test coverage now that the regression was reverted.
Comment #16
joelpittetI temporarily reverted the revert from #2735997: Decimal separator and precision settings unavailable when aggregating decimal fields locally, including the flawed change to
Sql::getAggregationInfo(), and ran these tests to confirm they go red 🔴 as expected.This is test-only, with no runtime code changes and hope to land this in before #2735997: Decimal separator and precision settings unavailable when aggregating decimal fields which I already checked and also passes with these tests as well locally.
I also ran the full
QueryGroupByTestlocally: passing on SQLite. The tests passed after I caught up with main in gitlab-ci here and still pass 🟢 after my small local sort fix. The sort criteria are needed because grouped-query row order is database-dependent: it passed on MySQL CI but failed on SQLite without deterministic ordering.RTBC thanks @acbramley for demonstrating the problem and pointing out my
git bisectsleuth work was way off the mark!Comment #17
joelpittetReally hoping to get this in then right after #2735997: Decimal separator and precision settings unavailable when aggregating decimal fields
Comment #18
joelpittetComment #20
catchCommitted/pushed to main and 11.x, thanks!