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
