Doctrine DBAL
  1. Doctrine DBAL
  2. DBAL-180

Documentation states that Doctrine 'decimal' (DecimalType) is mapped to PHP 'double', however, string is returned

    Details

    • Type: Documentation Documentation
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.1.2
    • Fix Version/s: None
    • Component/s: None
    • Security Level: All
    • Labels:
      None

      Description

      At http://www.doctrine-project.org/docs/orm/2.1/en/reference/basic-mapping.html#doctrine-mapping-types, it is stated that:

      "decimal: Type that maps an SQL DECIMAL to a PHP double."

      However, in the commit history, we can see that the casting to a float is removed: https://github.com/doctrine/dbal/commits/master/lib/Doctrine/DBAL/Types/DecimalType.php. Casting to a double is not possible in PHP?This seems to result in a float as well, that is probably why it was removed.

      I found this out when using PHP's 'is_double()' function (alias of is_float()) to check whether a decimal property was set or not.

      Suggestion is to either:

      • cast to a double (which seems not possible)
      • cast to a float (why was this removed?)
      • do nothing to the code, update documentation that string is returned.

      In my check function I guess I will use the is_numeric() function.

        Activity

        Hide
        Roel Harbers added a comment -

        I would strongly suggest to leave the behaviour as-is, and fix the documentation, because of all the trouble associated with floating point and rounding. People use the DECIMAL type to prevent those issues, so having the ORM convert it to floating point again would be pretty bad.

        Show
        Roel Harbers added a comment - I would strongly suggest to leave the behaviour as-is, and fix the documentation, because of all the trouble associated with floating point and rounding. People use the DECIMAL type to prevent those issues, so having the ORM convert it to floating point again would be pretty bad.
        Hide
        Patrick McDougle added a comment - - edited

        I have submitted a pull request on this issue on github. Hopefully the doc will be updated soon so other people don't expect the wrong behavior!

        https://github.com/doctrine/orm-documentation/pull/93

        Mods, this issue can probably be closed.

        Show
        Patrick McDougle added a comment - - edited I have submitted a pull request on this issue on github. Hopefully the doc will be updated soon so other people don't expect the wrong behavior! https://github.com/doctrine/orm-documentation/pull/93 Mods, this issue can probably be closed.
        Hide
        Oleg Namaka added a comment -

        Leaving decimal values as strings creates another issue with unnecessary entity updates because old and new same values have different types: old value is always the string type, the new one - decimal. If an old value is '10.00' as a string and the new value is 10 decimal than Doctrine will issue the UPDATE statement for that entity. This is plainly wrong IMHO.

        Show
        Oleg Namaka added a comment - Leaving decimal values as strings creates another issue with unnecessary entity updates because old and new same values have different types: old value is always the string type, the new one - decimal. If an old value is '10.00' as a string and the new value is 10 decimal than Doctrine will issue the UPDATE statement for that entity. This is plainly wrong IMHO.
        Hide
        karlie verkest added a comment -

        There may be other issues around comparison. I'd rather be comparing numeric types than strings when comparing "decimal" values.

        Show
        karlie verkest added a comment - There may be other issues around comparison. I'd rather be comparing numeric types than strings when comparing "decimal" values.
        Hide
        Steve Müller added a comment -

        I don't think we can fix this in DBAL. We should leave the decimal values retrieved from database as string for the obvious conversion problems. AFAIK the documentation in ORM has also been updated. Don't know about ORM issues with entity updates, but I don't see any further todo here in DBAL. Can this ticket be closed?

        Show
        Steve Müller added a comment - I don't think we can fix this in DBAL. We should leave the decimal values retrieved from database as string for the obvious conversion problems. AFAIK the documentation in ORM has also been updated. Don't know about ORM issues with entity updates, but I don't see any further todo here in DBAL. Can this ticket be closed?
        Hide
        Oleg Namaka added a comment - - edited

        @Steve Muller, is it feasible to change the way decimal values are compared from strict === to == to mitigate the issue with unnecessary updates:

        If an old value is '10.00' as a string and the new value is 10 decimal than Doctrine will issue the UPDATE statement for that entity.

        This is a very serious Doctrine shortcoming as for every single entity that has at least one decimal field with no real value changes updates still will be issued.

        Show
        Oleg Namaka added a comment - - edited @Steve Muller, is it feasible to change the way decimal values are compared from strict === to == to mitigate the issue with unnecessary updates: If an old value is '10.00' as a string and the new value is 10 decimal than Doctrine will issue the UPDATE statement for that entity. This is a very serious Doctrine shortcoming as for every single entity that has at least one decimal field with no real value changes updates still will be issued.
        Hide
        Steve Müller added a comment -

        Oleg Namaka I understand that. But IMO this is an issue that has to be adressed in ORM because casting the values in the DBAL type breaks the precision/correctness of the original database value in some circumstances. Therefore the only possible solution can be to fix this in ORM IMO.

        Show
        Steve Müller added a comment - Oleg Namaka I understand that. But IMO this is an issue that has to be adressed in ORM because casting the values in the DBAL type breaks the precision/correctness of the original database value in some circumstances. Therefore the only possible solution can be to fix this in ORM IMO.

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Menno Holtkamp
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: