Thank you very much for the examples, Bruce. I will try one of the two approaches below to see which one works best.
Thank you again. --- Bruce Snyder <[EMAIL PROTECTED]> wrote: > > Konrad wrote: > > > Bruce, Werner, do you guys have any examples of > > self-referential relationships? > > > > I'd really like to use Castor on my project. > > > > Thanks... > > > > > > --- Konrad <[EMAIL PROTECTED]> wrote: > > > >>Date: Tue, 25 May 2004 13:22:42 -0700 (PDT) > >>From: Konrad <[EMAIL PROTECTED]> > >>Subject: [JDO] Example of self-referential > >>relationship > >>To: castor <[EMAIL PROTECTED]> > >> > >>Hello. > >> > >>I read the FAQ about self-referential > relationships > >> > > > > > (http://castor.exolab.org/jdo-faq.html#I-have-an-object-that-holds-a-relation-to-itself.-Does-Castor-support-this?), > > > >>but is there an example of how to do this in > Castor? > >> > >>The object that can refer to itself is TYPE, and a > >>MERCHANT can have many TYPEs. In the database, > this > >>is represented with the following tables: > MERCHANT, > >>TYPE, and MERCHANT_TYPE (the table allowing a > >>MERCHANT > >>to be associated with several TYPEs). Is this > >>possible in Castor? > > My apologies for not responding sooner, Konrad. I've > just been very busy > lately. > > Unfortunately I do not have a working example of the > either workaround, > but helping you understand it via email shouldn't > too terribly > difficult. Let's consider the explanation in the FAQ > item mentioned > above for the first workaround listed below: > > 'One way is to manage this type of relationship > manually. For example, > let's say that a parent object FolderA needs to hold > references to child > objects FolderB, FolderC and FolderD. The Folder > object contains not > only a property to hold its own id, but also a > property to hold its > parent id (we'll call this parentId). The parentId > property is used to > determine if there is a relationship to another > Folder object. If > parentId is null, there is no relationship. If > parentId is populated, > there is a relationship and the object tree can be > walked by comparing > the object id to the parentId. When the two > properties are equal, you're > at the top of the tree.' > > Below is a quick example of the Folder object: > > public class Folder > { > /** > * This id is only populated if this folder has > a parent folder. > */ > public int _parentId = 0; > > public int _folderId = 0; > > ... > > /** > * If this method returns null then there is no > parent folder. > */ > public int getParentId() > { > return _parentId; > } > > public void setParentId( int parentId ) > { > _parentId = parentId; > } > > public int getFolderId() > { > return _folderId; > } > > public void setFolderId( int folderId ) > { > _folderId = folderId; > } > > > ... > } > > Based on the description for the first workaround > above, when FolderD is > fetched from the database, if a call to > FolderD.getParentId() returns > null, there is no parent folder. If it does return > an id then use this > id to fetch the parent folder from the database. > Continue doing this > until the getParentId() method returns null. When it > does return null, > then you know you're at the top of the folder tree. > > This particular workaround incurs some additional > overhead because it > roundtrips to the database for each Folder object. > Therefore this > workaround is just that, it's a workaround rather > than a real solution. > > The second workaround described in the FAQ is listed > below: > > 'Another say to solve this problem is to make use of > an intermediary > object. For example, a Folder object contains a > Reference object in lieu > of the actual Folder object. The Reference object is > somewhat of a proxy > object whereby it only contains enough information > to identify the > object to which the Reference object refers. Then > the Folder object can > be easily instantiated via the information contained > in the Reference > object.' > > Below is an example of each object: > > public class Folder > { > public FolderReference _ref = null; > > public getFolderReference() > { > return _ref; > } > > public void setFolderReference( FolderReference > ref ) > { > _ref = ref; > } > > ... > } > > public class FolderReference > { > public Folder _folder = null; > > public Folder getFolder() > { > return _folder; > } > > public void setFolder( Folder folder ) > { > _folder = folder; > } > > ... > } > > To use the objects above, both the Folder object and > the FolderReference > objects are mapped in the mapping descriptor. The > difference with this > workaround is that when a given Folder instance is > queried, Castor can > load the FolderReference object too. > > I've used this particular object relationship to > mitigate the > self-referencing relationship. It's not a bad one as > far as performance, > but it doesn't really fit into an object-oriented > model very well. But > when you consider > > I'm not sure if this answers your questions. If not, > please continue to > reply to this thread with any additional questions > or clarifications. > > Bruce > -- > perl -e 'print > unpack("u30","<0G)[EMAIL PROTECTED]&5R\\"F9E<G)E=\\$\\!F<FEI+F-O;0\\`\\`");' > > The Castor Project > http://www.castor.org/ > > Apache Geronimo > http://incubator.apache.org/projects/geronimo.html > > > > ----------------------------------------------------------- > > If you wish to unsubscribe from this mailing, send > mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-user
