Speaking of complex models. How about the case where one object extends another, SubObject extends BaseObject and a third object has a reference to a collection of BaseObjects. Is there any way to cast the resulting BaseObjects to SubObjects.
Thanks, Ron -----Original Message----- From: Bruce Snyder [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 27, 2002 1:12 PM To: [EMAIL PROTECTED] Subject: Re: [castor-dev] castor and complex data-models This one time, at band camp, Steffen Fiedler said: SF> SF>"Bruce Snyder" <[EMAIL PROTECTED]> wrote: SF> SF>> This one time, at band camp, Steffen Fiedler said: SF>> SF>> SF>Hi, SF>> SF> SF>> SF>I have an application that works with objects, that are linked in many SF>> SF>ways among each other. SF>> SF>What is the best way to save them? SF>> SF>I try to to it by long transactions, because the Objects are used while SF>> SF>the whole application SF>> SF>and and i don't want to hold one transaction all the time to hold them SF>> SF>persistent. SF>> SF>Its a multi-user web-application and i can't be sure, that the conection SF>> SF>will be closed correctly. SF>> SF>So i just open a connection, when some objects have to be SF>> SF>read/saved/updated and want to SF>> SF>save them by long transactions. When i do this: SF>> SF> SF>> SF>db.setAutoStore(false); SF>> SF>db.begin(); SF>> SF>db.update(myObject); SF>> SF>db.commit(); SF>> SF> SF>> SF>i get the error: SF>> SF> SF>> SF>Commit failed: org.exolab.castor.jdo.TransactionAbortedException: Nested SF>> SF>error: SF>> SF>org.exolab.castor.jdo.PersistenceException: Object, SF>> SF>com.sourcepark.ticketsystem.Ticket@305236, SF>> SF>links to another object, com.sourcepark.ticketsystem.Priority@6a0105 SF>> SF>that is not SF>> SF>loaded/updated/created in this transaction SF>> SF> SF>> SF>If i set db.setAutoStore(true) i get the error: SF>> SF> SF>> SF>Error while saving object: SF>> SF>org.exolab.castor.jdo.DuplicateIdentityException: update object SF>> SF>which is already in the transaction SF>> SF> SF>> SF>because i use some objects in many ways, i.e. the object 'state' can be SF>> SF>a pre-state and a SF>> SF>successor-state for another object and there are many other relations SF>> SF>like this. I've tried SF>> SF>to set the affected objects to access="read-only" in mapping.xml but SF>> SF>without success. SF>> SF> SF>> SF>In the JDO-FAQ is written, that castor only supports bi-directional SF>> SF>relationships, does SF>> SF>that mean, if object1 contains a reference to object2, object2 should SF>> SF>contain a vector SF>> SF>of object1's? SF>> SF> SF>> SF>I expanded my mapping.xml, but now castor works very slowly, when i load SF>> SF>a single SF>> SF>user, the whole datamodel is loaded from DB cause all objects are linked SF>> SF>among each other. SF>> SF>Is it usefull to use castor for a web-application with complex SF>> SF>datamodel? Whats about SF>> SF>performance when there are many users and large databases. Could SF>> SF>lazy-loading solve this SF>> SF>problem? SF>> SF> SF>> SF>I've appended the whole mapping.xml for getting an impression about the SF>> SF>object-structute. SF>> SF>My main question is, if it's advisable to use castor for a multi-user SF>> SF>web-application with SF>> SF>such a datamodel and if yes, what is the most performance-friendly SF>> SF>approach to save and SF>> SF>load the objects. SF>> SF>> Steffen, SF>> SF>> I've found that Castor has it's limits with regards to very, very complex SF>> object models. Much of my experience with this has been learned at my SF>> day job where I work on a GIS application using highly complex data SF>> in a highly complex object model (polygons, etc). BTW, I would NOT SF>> consider your object model to be highly complex. Castor should handle SF>> this just fine. SF>> SF>> I've also found that Castor does not enforce the bi-directional relations SF>> at all times (as is stated in the JDO FAQ). This being said, I've used SF>> Castor in the past with an object model similar to yours by not mapping SF>> things bi-directionally. (This took some time to figure out because there SF>> are situations where Castor wants a bi-directional mapping and other SF>> situations where it doesn't matter (there are threads on the mailing SF>> list discussing this, unfortunately I don't know the ins and outs of SF>> this off the top of my head).) The situation to which I'm referring SF>> was a mutli-user web app using long transactions. In this setting, SF>> Castor performed just fine. SF>> SF>> Unfortunately I have no easy answer for this situation. However, SF>> if you take the time to experiment with the removal of many of the SF>> bi-directional references in your object model, I believe you'll start SF>> to get the results you want. SF> SF>Ok thanks, i'll try a bit around. SF>How can i avoid the Exception: SF>"org.exolab.castor.jdo.DuplicateIdentityException: update object SF>which is already in the transaction" SF>while using long transactions? The affected objects don't have SF>to be changed in this situation and read-only="true" doesn't SF>change anything. SF>The only way i found is to change objects by loading them and SF>all there linked objects in short transactions. SF>But i think, its not the best way... Have you tried to use jdo.setAutoStore( true )? I'm curious to know how that affects your situation. 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 ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
