| Hi Michael,
Definitely add the setUp changes. But I'd like to get some feedback from others on changing the value. It appears to me that we now understand why the comparison was going wrong. And it is a bug that we don't match the float type in memory to the proper db type.
Craig On Dec 18, 2005, at 3:06 PM, Michael Bouschen wrote: Hi Craig,
we could go through the schema and change the column type as you described, but maybe we should treat this as a separate issue. I still would like to change the float value and add the setUp changes as implemented in the patch. What do you think?
Regards Michael
Craig Russell commented on JDO-206: -----------------------------------
The issue here is that Derby treats the FLOAT data type is used to represent both single- and double-precision floating point numbers. To get a single-precision value in the database, you have to use either REAL data type or specify a length on FLOAT. Everywhere we really want a 32-bit floating point number to be stored, we need to specify REAL or FLOAT(24) as the column type.
JDOQL test NotEquals comparing floating point numbers -----------------------------------------------------
Key: JDO-206 Project: JDO Type: Bug Components: tck20 Reporter: Andy Jefferson Assignee: Michael Bouschen Attachments: JDO-206.patch
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
-- Michael Bouschen [EMAIL PROTECTED] Engineering GmbH Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin
|
smime.p7s
Description: S/MIME cryptographic signature
