This one time, at band camp, Boris Klug said: BK>sorry about my confusing English. I will try to explain my problem again:
No problem, Boris. Thank your for being patient with me! BK>We have database tables with timestamps, database is ProstgreSQL. Timestamps BK>in PostgreSQL can have a milliseconds part like in: 2002-10-05 10:15.1234+02 BK> BK>Now we want to map these tables to Java objects using Castor JDO using the BK>following mapping: BK> BK> <class name="MyObject" BK> identity="id" BK> key-generator="MAX"> BK> <map-to table="sys_users" /> BK> <field name="id" type="integer"> BK> <sql name="id" type="integer" /> BK> </field> BK> <field name="login" type="string"> BK> <sql name="login" type="char" /> BK> </field> BK> <field name="instime" type="timestamp"> BK> <sql name="instime" type="timestamp" /> BK> </field> BK> </class> BK> BK>To load an object I do an OQL, than change the object using the getter/setter BK>and do a db.commit(); BK> BK>Now the point: If the timestamp, that was originally in the database when I BK>load the object has more than three digits (three, I stated two in my first BK>email, that was wrong), I get the exception "Object was modfied by another BK>transaction". Even when I do not change anything at the object, I get this BK>exception. BK>That why I included the following table: BK> BK>BK>klug=# select login, instime from sys_users; BK>BK> login | instime BK>BK>------------+------------------------------- BK>BK> admin | 2002-10-25 15:28:01.51+02 BK>BK> klug | 2002-10-25 15:28:01.51+02 BK>BK> test | 2002-10-25 15:28:01.513514+02 BK> BK>As you can see, the object with login "test" has one of this long milliseconds BK>timestamp. Because of this, you get the exception when you get these object BK>and do a commit, but not when you get one of the others. BK> BK>> Because I don't completely understand your problem, so I'm going to BK>> paraphrase your statements. Please tell me if I'm correct or not: BK>> BK>> - With Castor, the timestamps are not handled correctly. BK>Yes! BK> BK>> - With psql, the timestamps are handled correctly. BK>Yes again! BK> BK>Hope this explanition is a little bit better. If it is nessesary, I can create BK>a small sample application which reproduce the bug. A test case would be great (especially one that follows the Castor Test Framework (http://www.castor.org/test-framework.html) format so I could plug it into our test suite). I'm following your explanation now, but a test case would really allow me to pinpoint the problem quicker (I hope!). Bruce -- perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");' ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
