Drupal\field\Tests\Number\NumberFieldTest fails on SQLite

This is a float precision issue - mysql and postrges by default are 4 bytes but sqlite is 8.

So let's test the 'number_formatter' rather than the database backend. But to be honest this issue makes me think we should remove the float field because its behaviour is so unpredictable.

This passes on pgsql, mysql and sqlite.

Alternatively we could just make all float fields big. Which would have the advantage of making float fields less surprising.

@amateescu I'm not sure what you mean?

+++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldWidget/NumberWidget.php
@@ -73,6 +73,14 @@ public function formElement(FieldItemListInterface $items, $delta, array $elemen
+    // Ensure that floating point numbers are represented correctly to account
+    // for differences in various storage engines. For example, SQLite stores
+    // 8-byte IEEE floating point numbers by default, while MySQL and PostgreSQL
+    // store 4-byte floating point numbers.
+    if ($this->fieldDefinition->getType() == 'float') {
+      $value = sprintf ("%.2f", $value);
+    }

But this does not work as you expect :)... 3.141 would be stored correctly in all engines in HEAD. The point can float :)

Just uploading #3 again so that the patch @amateescu rtbc'd is last.

I think 4 byte floats are designed to cause user frustration and we should consider either removing the field or making it be double instead. I have no idea how to explain to a user that 10000.1 and 3.141 are stored without alteration but 1234.5678 is stored as 1234.57. Moving to doubles mitigates this problem to a certain extent but I still wonder if we should just ditch floats in favour of decimals.

Testing the update path once a float field exists with data has shown something interesting. The update appears to be successful but it is not - the float is not changed to a double - and nothing is reported to the user. And then the update does not show up again! If there is no data the update works and the float is changed to a double as expected. I think in this instance we will need to write an upgrade function to handle the data change.

I think given the issues around this in order to have sqlite tests pass I think we should commit #2. Since that passes on all dbs and tests our code rather than database differences.

Opened:

• #2542748: Automatic entity updates can fail when there is existing content, leaving the site's schema in an unpredictable state
• #2542760: Mark float and list (float) field types as no_ui

as followups.