[DBAL-180] Documentation states that Doctrine 'decimal' (DecimalType) is mapped to PHP 'double', however, string is returned Created: 11/Nov/11  Updated: 28/Dec/13

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.1.2
Fix Version/s: None
Security Level: All

Type: Documentation Priority: Minor
Reporter: Menno Holtkamp Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
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.



 Comments   
Comment by Roel Harbers [ 19/Mar/12 ]

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.

Comment by Patrick McDougle [ 26/Apr/12 ]

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.

Comment by Oleg Namaka [ 24/May/12 ]

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.

Comment by karlie verkest [ 20/Dec/12 ]

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

Comment by Steve Müller [ 28/Dec/13 ]

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?

Comment by Oleg Namaka [ 28/Dec/13 ]

@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.

Comment by Steve Müller [ 28/Dec/13 ]

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.

Generated at Wed Jul 23 14:18:12 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.