Christoph, thanks for confirming this. Anyhow, can I please ask you to add your detailed findings to the existing bug report, and I'll assign myself later on today. I've got a couple of questions, and maybe I'd like to ask for a favour or two, and I'd rather do this ion the context of bugzilla.
Werner On Fri, 30 Jan 2004 08:30:23 +0100, Ernst, Christoph (dit-extern) wrote: >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 > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
