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 flexcoders@yahoogroups.com, Kevin <[EMAIL PROTECTED]> 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
>
