I did a big commit to both sourcetrees last night that should fix
this problem; please try it out. (I used your suggested fix.)

(I agree with your comment about nanos, but I'm trying to be very
"correct" here.)

Thanks for tracking this down.

Gavin


> hi,
>
> for this test, i'm using hsqldb (1.7.1).. but i'm not quite sure what
> this would have to do with the jdbc driver itself - in this case, we're
> only talking about two inserts, there's nothing to be read back from the
> db... OTOH, the jdk itself (i'm using 1.4.1_01) does silly things when
> creating new Timestamps( d.getTime() ) - the nanosec portion is
> different depending on the milliseconds... personally, i wouldn't mind
> if hibernate totally ignored the nanos, comparing on the millisec
> precision... never in my life i needed that, and if i would be into that
> level of detailed measurements, i would probably use my own datatype for
> that, since the built in java date classes make my eyes twitch
> uncontrollably...
>
>    viktor
>
>
> On Wed, 15 Jan 2003 17:43:03 +1100 (EST), "Gavin King"
> <[EMAIL PROTECTED]> said:
>> Damn! The number of times I have had to change TimestampType to cope
>> with all the various quirks of different databases ...... its driving
>> me crazy ...... these kind of issues SHOULD be defined by the JDBC
>> standard. What database are you using?
>>
>> I will look carefully at this tonight.
>>
>> > On Tue, 14 Jan 2003 21:55:49 -0500, "Viktor Szathmary"
>> > <[EMAIL PROTECTED]> said:
>> >
>> >> i found out more after playing around for a littlebit... it turns
>> out one of the properties in Bar is a java.util.Date... if i remove
>> that property from the mapping, everything's cool, it does 2
>> inserts as expected.. however, with the Date there, i believe an
>> equality check fails (i assume hibernate internally represents it
>> as a
>> >> java.sql.Timestamp so the comparison is screwed)...
>> >
>> > i took a glance at TimestampType.java, seems to me that it assumes
>> that the nanosecond portion will be zero when initially creating the
>> Timestamp( date.getTime() )... that's unfortunately not the case...
>> dates are evil in java (and in general too :) so perhaps a
>> t.setNanos(0) would do after the date->timestamp conversion, or
>> changing the equals(x,y) implementation....
>> >
>> >    viktor
>> > --
>> >
>> >   [EMAIL PROTECTED]
>> >
>> > --
>> > http://fastmail.fm - Same, same, but different...
>>
>>
>>
>>
> --
>
>   [EMAIL PROTECTED]
>
> --
> http://fastmail.fm - One of many happy users:
>   http://www.fastmail.fm/docs/quotes.html





-------------------------------------------------------
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
_______________________________________________
hibernate-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hibernate-devel

Reply via email to