intermediary object in a many-many relationship

[ConvertFromOldNGs]

by Michael Patricks >> Wed, 18 Aug 2004 3:44:15 GMT

Hi

I am creating references for two objects that are essentially related in a many-many relationship.

However, the relationship between the two objects also includes some attributes. So to solve this problem I have created an intermediary object. E.g:

ThisObject and ThatObject are the two main objects. They are related to each other through an other Object, MiddleObject.
The MiddleObject then has a reference to each of the two main objects, myThisObject and myThatObject. The two main objects then have a inverse collection on each called allMiddleObjects.

My problem is: Have i implemented this correctly? MiddleObjects should never exists without valid references to both the main objects ThisObject and ThatObject. I have implemented the inverses as having the collection as the manual side and the straight reference as the automatic. I thought this would ensure that programmatically it would be hard for the MiddleObjects to be manipulated to the point that they no longer to belonged to either one or both of the main objects. The deletion of the main Objects is also handled so that all the related MiddleObjects are removed from both collections of the ThisObject and ThatObject then deleted.

As for the key attribute of the MiddleObject, there is no defining identifier for them (it holds three decimal fields for currency values) so i thought i would either have an arbitrary attribute made up of both the key attributes on the main Objects or have two attributes which hold the actual values of the main Objects' key attributes themselves.

Is there a better way to do this?

Cheers

Mike

[ConvertFromOldNGs]

by Darrell Duniam >> Wed, 18 Aug 2004 4:34:19 GMT

This also is my preferred technique with many-to-many relationships. It makes the relationship less complicated, and with both references on MiddleObject having auto-inverses, should an instance be deleted (intentionally or otherwise), both sides of the relationship will still be cleaned up by JADE.

regards,
darrell.

[ConvertFromOldNGs]

by Patwos >> Wed, 18 Aug 2004 21:08:33 GMT

Further to Darrell's comments, even if you at the time of designing have no requirement for an intermediary class it is often worthwhile putting one in anyway to make it more easily extensible should you find you do have information you need to store on that relationship as development proceeds. This is particularly the case should you already have deployed production environments as it removes the need for any fixup scripts to populate a new intermediary class.

As regards the problem with no obvious key to use on the intermediary class, it may be an opportunity to utilise a keypath for the dictionary key. You seem to want to use a combination of properties on ThisObject and ThatObject so your keys could look something like the following:

Class: IntermediaryObjectDict (3164)
Superclass: MemberKeyDictionary
Access: public
Type: real
Lifetime: all all-subclasses
Default: persistent
Maps: SampleMap

------- Collection Class Details -------
Membership: IntermediaryObject size = 6
Maximum Block Size = 100 entries per block (7200 bytes)
Load Factor = 66%
Exclusive instances mapped to: mapfile of owner
Member Keys:
myThatObject.thatProperty (String) ascending, case sensitive, sort order: Binary
myThisObject.thisProperty (String) ascending, case sensitive, sort order: Binary
Duplicates are not allowed

By using a keyPath to ThatObject::thatProperty and ThisObject::thisProperty rather than replicating this information onto your IntermediaryObject, you are not unnecessarily polluting the object model for your IntermediaryObject class with properties who's sole purpose is to replicate information from related object classes to use as dictionary keys.

Hope that helps,
Pat.

[ConvertFromOldNGs]

by Trailing Drones >> Thu, 19 Aug 2004 0:56:42 GMT

I'm with Pat on the use of intermediate mapping objects as a technique for design-hedging.

But I'm surprised to see keypaths recommended when there's "no obvious key". If you don't need the mapping objects in any particular order, why not use a set? If you're determined to use dictionaries and you're anticipating that you will want to ask ThisObject if it's related to ThatObject, why not key by the oids?

Also, Michael said "The deletion of the main Objects is also handled so that all the related MiddleObjects are removed from both collections of the ThisObject and ThatObject then deleted" - you can achieve that by making the both collections parent-child references.

[ConvertFromOldNGs]

by Michael Patricks >> Thu, 19 Aug 2004 1:41:03 GMT

Thats the implementation that I ended up going with: I have keyed by the opposing oids and used parent-child references. I also have a collection on a Company object by both reference oids of the two main Objects.

Thanks for your help everyone.

[ConvertFromOldNGs]

by Patwos >> Thu, 19 Aug 2004 5:24:03 GMT

As it happens, when I started writing my reply I did actually intend to mention he could use Sets if he had no requirement as regards order or the need to do getAtKey operations. I guess I got too carried away with telling him he didn't have to replicate information in order to achieve his desired keys if that's the way he wanted/needed to go and went and forgot to mention the Set option as part of my posting.

Pat.

[ConvertFromOldNGs]

by Trailing Drones >> Thu, 19 Aug 2004 5:39:53 GMT

Don't beat yourself up over it Pat.