I had the exact same problem, I think the issue is not really inheritance but the graph of objects being arbitrarily complex and deep.
I got round it by ditching the managed associations completely and going for RPC calls to my Java classes using RemoteObjects. I found myself too tangled by the destinations and weird and undesirable behaviour of the framework that I had no control over. In my case a close examination of the reality of the usage of my object model showed that I rarely had a true cyclic graph and in fact towards the edges it was much more like a directed acyclic graph, so I constrained the application to enforce that and altered the server transaction to lift the graph in little hierarchies rather than as individual components. I think it is always a good idea to make sure your model fits exactly what you are doing rather than some potential fringe use cases at the cost of complexity. You have probably done that already. The suggested solution of separating the objects and the relationships is a great idea as well, and you can reconstitute it quite easily on the client side if you need to. This is probably my next major architectural overhaul. On the client the use of a Dictionary or Object as a proxy for a hash map offers some interesting architectural opportunities. As an aside I also found that very deep hierarchies of objects caused Hibernate to create a lot of joins and or inefficient sub-queries and it was impractical for my purposes from a performance standpoint. I found iBatis a much better fit because 1) I have SQL expertise and 2) I don't have the issue of having to make sure my persistence tier works on all known rdbms's so I could take advantage of some db specific features. --- In [email protected], "Josh VanderBerg" <[EMAIL PROTECTED]> wrote: > > I tend to eschew implementing inheritance in data model that needs to > be persisted to a database - preferring (in this example) instead to > overload PetVO with all of the possible pet properties and give it a > petType property. Regardless of whether or not you implement > inheritance, the PetVO must have a property: > > public var friends : ArrayCollection; > > In the database you will have to have a table something like the following > > PetRelationship > > relationship_id INT (Autonumber) - surrogate key > pet_id INT - FK Pet table > friend_id INT - FK Pet table > > And use it to do your data services mapping, and map it appropriately > in Hibernate as well (if that's what you are using). You could > optionally expose this object as an endpoint itself, so it would be > the home of the "friends" lists. In this case the PetVO would just > have a property: > > public var relationship : PetRelationship; > > And your mapped PetRelationShipVO would store the ArrayCollection of > friends. > > Now, the application of either would be relatively obvious in the case > where you don't implement inheritance in the datamodel. I am sure > there is a way to do it with inheritance - I've just never done it - > but the approach would be similar, you really need a many-to-many > mapping table at the PetVO level. > > __ > Josh Vanderberg - vanderblog.typepad.com > > --- In [email protected], Kevin <lists@> wrote: > > > > DataServices experts, > > > > We are currently stumped on how to configure our data-management > > config to address a very specific data model that we have. I would > > love to get some ideas/feedback on how to solve this dilemma. Here > > is our problem (as simplified as possible). > > > > We have a number of objects that extend a root object like so: > > > > PetsVO(root object) > > extended by: > > - DogVO > > - CatVO > > - BirdVO > > - FishVO > > - RatVO > > > > Here is the problem. Each object can hold a collection of pet's > > objects. So in a social networking way, each pet can be linked to > > its pet friends. > > DogVO > > - holds collection of PetVO's > > CatVO > > - holds collection of PetVO's > > BirdVO > > - holds collection of PetVO's > > ... you get the idea. > > > > So, how do with deal with this in our destinations?? > > > > Option 1) Hierarchical management. > > - This works conceptually of course since no association tags are > > required to link the destinations together. However, we then have > > major scaling issues & no way to throttle individual destinations, > > etc... Not really a working solution unless your model was truly as > > simple as the one I am describing. > > > > Option 2) Use destinations to manage relationships. > > > > We set up destinations for each of these sub classes: > > dogs > > cats > > birds > > fish > > rats > > > > However, how do we associate the PetVO collection in each? > > > > <many-to-many property="pets" destination="???????" lazy="true" /> > > > > THOUGHT 1: If we have a pets destination and set up a "many-to-many" > > tag from "dogs" to "pets" then we create the problem where we are > > managing the same object in two different places. Plus when we add a > > "CatVO" to a "pets" collection in a "dogs" destination (as an > > example) DataServices initializes a createItem in the "pets" > > destination not knowing that the object already exists as part of the > > "cats" destination...not good. > > > > THOUGHT 2: We could set up a "many-to-many" tag in dogs to > > "cats"...however this obviously won't work when someone then adds a > > BirdVO to the collection. > > > > What to do?... I realize this is a silly example, but hopefully it > > illustrates the problem of integrating an object model which uses a > > lot of Base or Root objects into DataServices. > > > > Is there something we are missing or not understanding about how we > > could set this up? I would be interested to see if anyone has any > > solutions. > > > > (I should note that we are using Hibernate with Annotations.) > > > > Thanks for your help we look forward to any of your ideas, > > > > Kevin > > >
