Hi Werner, yes, this issue is exactly what we have also found. Next time we will search bugzilla first..
The method should return "new java.util.Date(timestamp.getTime())" and that's it. Then you don't need to add "dirty=ignore" to any timestamp field you have. Christoph -----Urspr�ngliche Nachricht----- Von: Werner Guttmann [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 30. Januar 2004 00:01 An: [EMAIL PROTECTED] Betreff: Re: [castor-dev] ObjectModifiedException when using timestamp fields Ernst, I assume this directly relates to the following bug entry http://bugzilla.exolab.org/show_bug.cgi?id=1462 If that's the case, can you please post your findings in the context of this bug report, and I'll try to take care of this issue. Werner On Thu, 29 Jan 2004 13:15:34 +0100, Ernst, Christoph (dit-extern) wrote: >> Hi, >> >> there are several threads in castor-dev concerning ObjectModifiedException >> when using timestamp fields. >> (see eg. http://www.mail-archive.com/[EMAIL PROTECTED]/msg14525.html) >> >> We also encountered this problem and found that the common answer to this >> problem is setting dirty=ignore for the timestamp fields. >> >> However, some debugging effort revealed, that maybe the reason lies within >> the castor type conversion. >> The code which converts from Timestamp to Date in >> org.exolab.castor.jdo.engine.SQLTypes reads as follows: >> new TypeConvertorInfo( new SQLTypeConvertor( >> java.sql.Timestamp.class, java.util.Date.class ) { >> public Object convert( Object obj, String param ) { >> java.sql.Timestamp timestamp = (java.sql.Timestamp) >> obj; >> return new java.util.Date(timestamp.getTime() + >> timestamp.getNanos() / 1000000); >> } >> } ), >> In my opinion it is not correct to add "timestamp.getNanos() / 1000000" >> here. The reason is that java.sql.Timestamp.getTime already adds the >> nanos. See java.sql.Timestamp: >> public long getTime() >> { >> long l = super.getTime(); >> return l + (long)(nanos / 1000000); >> } >> Thus you get back a timestamp which differs from the value initially read. >> >> I also believe that the code in TypeConvertorInfo( new SQLTypeConvertor( >> java.util.Date.class, java.sql.Timestamp.class )coud be simplified. You >> explicitely say "timestamp.setNanos((int) ((time % 1000) * 1000000));". >> Hoewever, this is already done by "new java.sql.Timestamp(time)" see the >> constructor of java.sql.Timestamp. >> >> In summary, the process is: >> When commiting, the method org.exolab.castor.jdo.engine.SQLEngine.store() >> creates the update statement which looks something like >> UPDATE "table" SET "field1"=:1, "time"=:2 WHERE "field1"=:3 AND "time"=:4 >> In fields :3 and :4 the original values are inserted. However, casting the >> initial values from Timestamp to Date dit not work correct (see above). >> For example you get the following: >> Field in statement | Field in DB >> 2004-01-28 10:09:06.124 | 2004-01-28 10:09:05.562 >> 2004-01-28 10:09:05.886 | 2004-01-28 10:09:05.443 >> As you see the milliseconds are taken twice. >> For this reason no dataset is found and finally the >> ObjectModifiedException is thrown. >> >> I guess we'll also live with the dirty=true-workaround, but if you confirm >> our conjecture, maybe you can fix this issue in one of the next releases? >> >> By the way, we are using Castor 0.9.5.2 with JDK 1.4.2_03. >> >> Best wishes >> Christoph >> >> > >----------------------------------------------------------- >If you wish to unsubscribe from this mailing, send mail to >[EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
