[ http://issues.apache.org/jira/browse/JDO-206?page=comments#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 and 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/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
