Fraction doesn't work with views SUM aggregation

I've been using this patch to fix up SUM(fraction) successfully for years now, but it has just stopped working and I'm having problems narrowing it down to the exact failure. I haven't been able to narrow down the timeframe for when the failure happened either, except that it was either last week, or all the way back in January. It doesn't seem to line up with releases of this module.

Key to it is that $field->field_alias == 'unknown' for all of the Fraction fields in a view. That was causing the complete failure of what this patch was doing.

I've reworked the patch from #11 into 3.x-1515840-fix-sum to at least give me the correct answers in $view->results at hook_views_pre_render() time, but all of the fields are still considered empty and rendered as such. It seems very much like the field_alias being considered the default "unknown" by the field handler is the bugbear.

I had to change ordering of the 'entity field' vs 'field_name' in field definition since every field now has 'field_name', even if it is an entity field. This was resulting in no fields being found for fraction base fields.

The attempt to compensate for the field_alias being missing is not the correct way to go. Determining why that is missing is where I am currently focussed.

I have not created a MR as this still needs work. Some additional eyeballs would be greatly appreciated. Dumping to 3.x branch.

@elc What version of Drupal core and Fraction are you using?

I wonder if this change has anything to do with it?

https://git.drupalcode.org/project/fraction/-/commit/f34523b9fe859f80745...

That is the only substantive change to the 2.x branch since January.

Key to it is that $field->field_alias == 'unknown' for all of the Fraction fields in a view. That was causing the complete failure of what this patch was doing.

Otherwise, I wonder if something changed in Drupal core / Views that could explain the new behavior you're seeing. 🤔

Site is running Drupal 10.4.6 and Fraction 3.0.1.

I've been searching Drupal Core for any related changes without any luck. I haven't figured out how field_alias is ending up either with no value set, or the value set being unknown. The field is present in the query while the alias is unknown, which is weird itself since there has already been an alias calculated as the array key, and set as a key in the array too.

I'll reverse that commit and see if it makes any difference. First look is that it's only the category name that has changed. Hard pressed to think that would make a difference.

I'll reverse that commit and see if it makes any difference. First look is that it's only the category name that has changed. Hard pressed to think that would make a difference.

That was my thought too, but maybe the category gets used somewhere along the way. Just a guess...

No difference found when changing the category back to a translated string.

Have found why the value is showing as empty:
Drupal\fraction\Plugin\Field\FieldType\FractionItem::setValue() is being called with $values = [[numerator] => 114.6800];, which results in a parent::setValue($values, $notify) call with that array, resulting in a null denominator.

Made this change to cope with that input (pushed to issue branch):

-    // If the decimal property is specified, use it.
-    if (is_array($values) && isset($values['decimal'])) {
-      $decimal = $values['decimal'];
+    if (is_array($values)) {
+      // If the decimal property is specified, use it.
+      if (isset($values['decimal'])) {
+        $decimal = $values['decimal'];
+      }
+      // If values array has been passed with only numerator and null
+      // denominator, treat it as if it was passed in as the decimal key.
+      elseif (isset($values['numerator']) && !isset($values['denominator'])) {
+        $decimal = $values['numerator'];
+      }
     }

Still unknown:
- Why field_alias is 'unknown'
- Why value is being set as numerator array instead of decimal array, or num+den array.
- What happened to cause of all of this

Pondering installing an older versions of Drupal + Fraction and investigating old behaviour to narrow down which version has contributed to the change.

Installed Drupal 10.4.1 + Fraction 2.3.1 which resulted in a working SUM display.

Some items of note:
- $field->field_alias is still 'unknown'
- Resulting SUM field is the following during hook_views_pre_execute
- Class: Drupal\views\Plugin\views\field\NumericField
- type: numeric

In Drupal 10.4.6 + Fraction 3.0.1:
- Resulting SUM field is:
- Class Drupal\fraction\Plugin\views\field\FractionField
- type: fraction_field

Also getting validation error in both:

display.default.display_options.fields.field_fraction	Default field	views.field.*	Yes	<array> 
'click_sort_column' is an unknown key because display.default.display_options.fields.field_fraction.plugin_id is fraction_field (see config schema type views.field.*).
'type' is an unknown key because display.default.display_options.fields.field_fraction.plugin_id is fraction_field (see config schema type views.field.*).
'settings' is an unknown key because [snip, etc]

Haven't had a chance to look deeper.

There was a now reverted core change which has caused the change in behaviour. The change was introduced in 10.4.6 when 2735997 hit.

🐛 Decimal separator and decimals settings ignored when aggregating decimal fields Needs work
🐛 [regression] COUNT aggregation no longer outputs count value for some fields Active
🐛 Upgrading from 10.4.5 to 10.4.6 removes views format plural on Content ID field Active

It removed the numeric field handler inside core/modules/views/src/Plugin/views/query/Sql.php
https://git.drupalcode.org/project/drupal/-/commit/59d79456a1a135b3d02bb...

End result is that after aggregation, instead of a numeric field being used for the result of the operation, it uses a Fraction field which is where the setValue(['numerator' => NN.NN]) happens.

Add a "me too" to the issue about fixing it up, and see where the core issue goes.