db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: [jira] Commented: (JDO-206) JDOQL test NotEquals comparing floating point numbers
Date Sun, 18 Dec 2005 23:30:41 GMT
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.


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
>>    [ http://issues.apache.org/jira/browse/JDO-206? 
>> page=comments#action_12360759 ]
>> 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
>>>         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
>>> 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		Tech@Spree Engineering GmbH
> mailto:mbo.tech@spree.de	http://www.tech.spree.de/
> Tel.:++49/30/235 520-33		Buelowstr. 66			
> Fax.:++49/30/2175 2012		D-10783 Berlin			

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

View raw message