> Ew, yuck, yeah, I see what the problem is. How would you express it in
SQL?
> Stored procedure, perhaps...
Prefer not - au revoir portability!
> Otherwise, you'll need to construct an inheritance tree somehow. If you
*know*
> that EJBs will be your only client, you could construct an RMI cache of
the
> inheritance tree at startup, and then access that from your bean. This
would
> be foul to try to maintain if the database was being updated externally,
though.
...which why neither I nor anyone else I know of has ever attempted to use
such a schema before. In praise of EJB, I can actually contemplate the
previously unthinkable.
> Perhaps the best way would be to have a Category bean. The home interface
has
> a create(...) method, a findByPrimaryKey(...) method, a findByName(...)
method
> etc. The remote interface has probably only two methods,
getSubCategories()
> and getMemberThings(). Then, in a finder somewhere, you get the Category
for
> the type you want, call getMemberThings() on it, add them to a Vector,
then
> recursively call getSubCategories(), calling getMemberThings() on each
one, and
> adding them to the Vector().
This is pretty much the way I'm heading at the moment.
> I don't know how this would perform; my suspicion is that it would get
rapidly
> worse as the network got more complex, and would of course not handle
circular
> references and the like.
Doesn't matter for the application I have in mind, which is charts of
accounts for financial accounting.
Historically accounting schemata have had separate tables for each possible
level of nesting and used placeholders to keep the nesting level constant.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
