This one time, at band camp, Fabio Andr�s Zorzan said:
FAZ>Bruce,
FAZ> I send you more details:
FAZ>
FAZ>Code of the Query and update
FAZ>-----------------------------------------------
FAZ>
FAZ> oql=db.getOQLQuery("select n from castor.Actor
FAZ>n");
FAZ> results=oql.execute(); //return ~40 Objects
FAZ> Object o;
FAZ> while(results.hasMoreElements())
FAZ> {
FAZ> o=((Object)results.next());
FAZ> v.add(o);
FAZ> }
FAZ>
FAZ> castor.Actor
FAZ>actor=(castor.Actor)vector.elementAt(5);// 1 or 2 ...
FAZ>I have the problem
FAZ> db.update(actor);
So because you're using db.upate(), you're using Castor's long transactions,
correct?
FAZ> <field name="creationDate" type="date"
FAZ>required="false" direct="false" lazy="false"
FAZ>transient="false">
FAZ> <sql name="creation_date" type="date"
FAZ>read-only="false" dirty="check" />
FAZ> <xml name="creationDate" node="element" />
FAZ> </field>
FAZ> <field name="updateDate" type="date"
FAZ>required="false" direct="false" lazy="false"
FAZ>transient="false">
FAZ> <sql name="update_date" type="date"
FAZ>read-only="false" dirty="check" />
FAZ> <xml name="updateDate" node="element" />
FAZ> </field>
I'm not sure exactly why this is occurring. However, an
ObjectModifiedException can be thrown when a field fails Castor's dirty
check (which uses .equals()). This can occur when using fields of type
float, double, date, etc. I notice that there are some date fields
above. Isolate these fields by instructing Castor not to perform its
dirty check on them like so:
<sql name="foo" type="date" dirty="ignore" />
See if the ObjectModifiedException goes away after taking this step.
This might then lead you down the road of locating the actual
problem.
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
