Not a bug $entity->isChanged('column') should return true in this case?

[Siropu]

Affected version

2.1.5

I have a decimal column with entity type set to float. If the value is 10.00 and I save the current entity with the same value $entity->isChanged('column') returns true. Input filter 'float' or 'unum' removes the decimal point so 10.00 becomes 10 and $entity->isChanged('column') consider those two different values, returning true.

 

[Mike]

Strictly speaking, this isn't unexpected due to differences between floats and decimals within MySQL. If this were to be something we'd change, it'd have to be implemented as a new entity data type.

To see what I mean, consider this test code:

$db = \XF::db();
$db->query('
   CREATE TEMPORARY TABLE test (
      float_col float,
      decimal_col decimal(10,2)
   )
');
$db->query('
   INSERT INTO test VALUES (10, 10), (10.5, 10.5)
');
\XF::dumpSimple($db->fetchAll("SELECT * FROM test"));

The result is:

array(2) {
  [0] => array(2) {
    ["float_col"] => float(10)
    ["decimal_col"] => string(5) "10.00"
  }
  [1] => array(2) {
    ["float_col"] => float(10.5)
    ["decimal_col"] => string(5) "10.50"
  }
}

Most notably, you'll see that the decimal column comes back as a string. This is because decimal is a fixed precision type in MySQL. If it came back as a float, you're susceptible to the standard float precision issues, which the decimal type avoids.

Thus, when you're setting your decimal column as a float type, we're converting to a float when you set the value, and then MySQL is converting that to the necessary format on save.

So if this behavior is important to you, you'd likely need to change the column's entity definition to a string type and manually convert it to the expected format in a validation method (such as by combining floatval+round).