| Craig Russell (JIRA) 2005-12-19, 8:45 pm |
| [ http://issues.apache.org/jira/brows...action_12360881 ]
Craig Russell commented on JDO-206:
-----------------------------------
The change looks good.
This sure had me puzzled for quite a while. The root cause of the issue was that the float values in the class were being mapped to FLOAT column types, which are double precision if no length is specified. Float values were converted to double values for
both comparisons and storage, so these would work fine. That is, if a float value of e.g. 234.23 were stored, it would be stored as 234.22999572753906. A query with a float parameter of 234.23 would compare the converted double value 234.22999572753906 an
d it would work. But a query with a BigDecimal parameter of 234.23 would be converted to a double value of 234.2300000000000, which does not compare equal to the column value.
The change looks good to check in.
> JDOQL test NotEquals comparing floating point numbers
> -----------------------------------------------------
>
> Key: JDO-206
> URL: http://issues.apache.org/jira/browse/JDO-206
> Project: JDO
> Type: Bug
> Components: tck20
> Reporter: Andy Jefferson
> Assignee: Michael Bouschen
> Attachments: JDO-206.patch, JDO-206.patch2
>
> The current TCK test (carried over from JDO 1.0) for NotEquals, uses != operator on floating point numbers. This is not a good practice, and is unreliable. Its probably the case that the Equals test uses == on the same content, which also is not a good
idea (as noted in the latest spec). These tests need reviewing and a reliable alternate strategy adopting
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secur...nistrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|