Thanks for the response. No, I never did get any other response on this subject. I understand the usage of various VO forms, but that still doesn't solve the problem. The main problem is that for this family chain, business needs are to read up/down n levels (ie, only the immediate 3 child generations). The current solution is to put that logic in its own routine to iterate and recurse n times, read each object, then read all the objects whose parent is that of the one just read, then iterate and recurse through those children and find all subsequent children...etc, ad nauseum. It works, it's just not as clean as we'd like it to be. Hence, the desire for a depth read control.
-- adam
From: "Brian Topping" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: <[EMAIL PROTECTED]> CC: <[EMAIL PROTECTED]> Subject: RE: [Xdoclet-user] defining self-referring / recursive CMR Date: Sun, 6 Jul 2003 15:11:01 -0400
Adam,
Did you get a solution for this yet?
The problem you are having is the value object has an aggregate. This would happen in either a compose or aggregate. And since your object is self-referential, it seems like you are stuck if you want an aggregate on this field, all or nothing.
The solution is to define multiple value objects for the bean. I always define two. One header from a typical class has these two lines:
* @ejb:value-object name="GL_AccountLight" match="light" * @ejb:value-object name="GL_AccountFull" match="*"
Then, each persistent field (but NOT relationships) get a tag of:
* @ejb:value-object match="light"
Then finally, you have to change your relation aggregate to return a xxxLight
value.
What happens then is you will get the node and one parent object, but without
the relation in the parent because the parent is a "light" object. This
"breaks the chain" in a recursive load into the value object.
I generally think this is important in general if you start using aggregates or composites in VO's. In a highly normalized database with a lot of relations and aggregates, you inevitably end up loading way more data than you want unless you use such a technique. This may be one of the reasons they are hard to use, it took me a few days to grasp. But I could be a dim bulb, what do I know... :-)
HTH,
-b
-----Original Message----- From: Adam [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 3:02 AM To: [EMAIL PROTECTED] Subject: [Xdoclet-user] defining self-referring / recursive CMR
I'm having an issue with defining a CMR on an object that has children/parents of itself
ie, table form:
node_id(tsn), node_name, parent_node_id (parent_tsn)
/**
* @ejb.interface-method
* @ejb.relation
* name="node-has-children"
* role-name="node"
* target-ejb="Unit"
* target-role-name="children"
*
* @jboss.target-relation
* related-pk-field="tsn"
* fk-column="parent_tsn"
*
* @ejb.relation
* name="node-has-children"
* role-name="children"
*
* @ejb.value-object
* aggregate="com.foo.UnitValue"
* aggregate-name="ChildNode"
* members="com.foo.UnitLocal"
* members-name="UnitValue"
* relation="external"
* type="Collection"
*/Is this the correct way to do this? It works.. but it works too well.
Once it loads the children for the object, it continues to load the children
for each of those children, and then the children of all of those children...
until it runs out of data.
Is the value object the problem? I'm using aggregate rather than compose,
as the objects aren't responsible for creating each other (this is a static
table).
Is this a factor of the way I've defined my relationship, or an issue with CMR or my app server? (I'm using JBoss 3.0.6). Is there a tag I can add to control the read depth? I've tried using the read-ahead strategy tag, but that doesn't seem to do anything (even when I set it to "none").
I'm sorry if this isn't the right place.. just checking all possibilities (I've posted on the java forums, too).
Thanks for all help!
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
