This one time, at band camp, Dave Carlson said:
DC>I've configured two Java classes, one that extends another, and have mapped
DC>them to two SQL tables, one corresponding to each class. The tables share a
DC>common primary key. I can query the subclass and recieve an object that
DC>includes all data from the tables representing both the super and subclasses.
DC>This works great.
DC>
DC>But I can't insert or update with these objects. I want to work primarily with
DC>the subclass. When I create a new Java object from the subclass and insert it,
DC>I get a null pointer exception, from this point:
DC>
DC> org.exolab.castor.persist.TransactionContext.create()
DC>
DC>Any suggestions?
DC>
DC>Also, when I call update(), or simply modify the object within a transaction, I
DC>get an error
DC>
DC>Caused by: org.exolab.castor.jdo.ObjectModifiedException: Transaction aborted:
DC>Object of type com.xmlmodeling.portal.data.PortalUser with identity 1 has been
DC>modified by a concurrent transaction at
DC>org.exolab.castor.jdo.engine.SQLEngine.store(Unknown Source)
DC>
DC>I saw a note that I must implement the jdo Timestampable interface for the
DC>superclass of an inheritance structure, so I've done that. But I don't
DC>understand this error about concurrent transaction. I only have one
DC>transaction running. I'm guessing there is something internal to JDO handling
DC>updates to the two tables representing this object.
DC>
DC>Thanks for any help on understanding the internals of JDO inheritance
DC>processing!
Dave,
I don't follow your statement, 'The tables share a common primary key.' Please
clarify.
The db.update() method is *only* for use with long transactions:
http://www.castor.org/long-transact.html
When using long transactions, any objects involved in the long transaction
must implement the TimeStampable interface so that Castor can perform it's
dirty check.
Without seeing the relevant portions of the mapping descriptor and client
code, I can't really say why you're receiving an ObjectModifiedException.
Oftentimes, this exception can be thrown for fields of type date, float
and double because they're failing the dirty check. If you're using
any of these types, utilizing the dirty="ignore" attribute of the <sql>
element in the mapping descriptor can help in hunting down the culprit.
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
