PHPUnit_Extensions_Database_DataSet_YamlDataSet getTable and formatting numbers

[Trudko]

I have fixture file

accounts:
  -
     creditor_account: x
     debitor_account: y
     amount: 5.00

but when I load it using:

$yamlDataset = new \PHPUnit_Extensions_Database_DataSet_YamlDataSet(
    $pathToFixture
);
return $yamlDataset->getTable($tableName);

my test fails because 5.00 gets formated to 5.

[elazar]

dbunit uses symfony/yaml for YAML parsing and doesn't appear to do any supplemental formatting of parsed data. It's currently using version 2.1.x. Could you try updating that to 2.3.x, which is the current stable version according to Packagist, and see if that addresses your issue? To do this, download Composer and run its update command.

[Trudko]

Hi , thank you for quick answer.

I did update the yaml parser and even tried loading data from yml directly in different code with same result. I guess this is not problem of DBUnit.

[elazar]

It appears this isn't a known issue with symfony/yaml. You might try filing an issue.

[Trudko]

Ok I will take a look at it, and I will let you know.

[Trudko]

I took a look at it and I am not sure about details, but symfony parser does format 5.00 to 5 so I am not sure if it should be handled on symfony side or on db unit.

[elazar]

Most likely on the Symfony parser side. Per my earlier comment, it's probably best to file an issue there. The most we could do for this issue would be to try to check the parser version and patch the behavior at runtime if needed.

[elazar]

This may actually be a wider issue. I happened across the fact that SQLite returns an integer value for a DECIMAL column when the value has no decimal component, which can lead to similar situations if your data set explicitly uses floating point numbers (i.e. by appending something like .00 to the integer value), where MySQL will return floating point values as one would expect.

The problematic area of code in dbunit appears to be this line. The tests for this class still pass with this patch applied and seem to resolve the issue of equivalent integer versus floating point numbers:

c9367a5538d6203071491eadf6f4e77dba56bcf3diff --git a/PHPUnit/Extensions/Database/DataSet/AbstractTable.php b/PHPUnit/Extensions/Database/DataSet/AbstractTable.php
index 7fc5945..e09f055 100644
--- a/PHPUnit/Extensions/Database/DataSet/AbstractTable.php
+++ b/PHPUnit/Extensions/Database/DataSet/AbstractTable.php
@@ -163,7 +163,16 @@ public function matches(PHPUnit_Extensions_Database_DataSet_ITable $other)

         for ($i = 0; $i < $rowCount; $i++) {
             foreach ($columns as $columnName) {
-                if ($this->getValue($i, $columnName) !== $other->getValue($i, $columnName)) {
+                $value = $this->getValue($i, $columnName);
+                $otherValue = $other->getValue($i, $columnName);
+                if (
+                    $value !== $otherValue
+                    && !(
+                        is_numeric($value)
+                        && is_numeric($otherValue)
+                        && (float) $value == (float) $otherValue
+                        )
+                ) {
                     $this->other = $other;
                     return FALSE;
                 }

Thoughts?

[elazar]

Actually, looks like a change like this is already present in sebastianbergmann/dbunit#114.

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity within the last 60 days. It will be closed after 7 days if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it has not had activity since it was marked as stale. Thank you for your contributions.