[ZODB-Dev] Re: [Zope3-dev] PROPOSAL: ZODB Relationships

[Phillip J. Eby]

At 11:28 AM 5/9/03 +0200, Roché Compaan wrote:
>On Thu, 08 May 2003 19:58:22 -0400
>"Phillip J. Eby" <pje at telecommunity.com> wrote:
> >
> > A final comment...  Once this takes directionality into consideration, you
> > might consider calling it an 'Association' rather than a 
> 'Relationship', as
> > it would then largely meet the MOF and UML semantics of an
> > "Association".  That is, an association is a collection of directed links
> > between objects.  It would then make sense to refer to refer to the
> > 'RelationshipView' as an 'AssociationEnd'.
>
>We used the term Relationship because the proposal is based on the
>entity-relationship model. I am not too familiar with MOF so maybe you
>can explain how it will apply to the current proposal.

 From the MOF 1.4 specification:

"Associations are the MOF Model’s primary construct for expressing the 
relationships
in a metamodel. At the M1 level, an M2 level MOF Association defines 
relationships
(links) between pairs of instances of Classes. Conceptually, these links do 
not have
object identity, and therefore cannot have Attributes or Operations."

If I understand the Relationship objects in your proposal, they correspond 
to the M1 level definition of an Association in UML and the MOF.  That is, 
they are a collection of links between objects.  An association provides 
operations to create and destroy links.  (The M2 level isn't relevant to 
this discussion, as the M2 level is the *specification* of the 
relationship; if your proposal involved ways of specifying the multiplicity 
of the ends, their aggregation kinds, what interface(s) objects on each end 
had to implement, etc., then that would be on the M2 level.)

Anyway, it's a straightforward mapping from the formal semantics of a UML 
association, to the relationships you defined, provided that the 
relationships are directional.


>  Thanks for your
>comments Phillip. I was hoping you say something because you must have
>thought about this when designing PEAK.

I thought about it quite a lot, but I haven't implemented such "external" 
relationship management because I have found that using Coad's "yellow role 
object" patterns (sort of like persistent adapters) are a cleaner solution 
for the actual use cases, at least for the kind of apps I work with.

But, if I were going to implement them, I'd say your proposal is in the 
right direction.  I understand that making relationships symmetrical 
certainly makes for easy lookups: just insert a pair for each direction, 
then do a one-way lookup.  Whereas directionality requires that you supply 
a parameter for the direction, and then either store the direction or use a 
forward map and a backward map.  OTOH, storing the forward and backward 
maps takes little more space than storing a map with both forward and 
backward entries.