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

[sean.upton at uniontrib.com]

Right... the same reason that UML doesn't use aggregation as an explaination
for associations...  Aggregation/containment is a refined type of
association, and a narrow one at that.

Sean

-----Original Message-----
From: Phillip J. Eby [mailto:pje at telecommunity.com]
Sent: Friday, May 09, 2003 8:41 AM
To: Shane Hathaway
Cc: roche at upfrontsystems.co.za; zodb-dev at zope.org
Subject: Re: [ZODB-Dev] Re: [Zope3-dev] PROPOSAL: ZODB Relationships


At 10:39 AM 5/9/03 -0400, Shane Hathaway wrote:
>Ugh, which mailing list should I send this to?  I'm going to pick zope-dev 
>since it's a fairly general list without too much traffic.

But I don't subscribe to it, so I'm redirecting to zodb-dev...  :)


>Phillip J. Eby wrote:
>>Issues:
>>1. "Global relationship repository" has no use cases, and smells like 
>>trouble.  Why not just explicitly store the Relationship() somewhere?
>>After all, every RelationshipView will have a reference to it.  (For 
>>ZODB4, a persistent module might be the natural place to put the 
>>"official" reference to the Relationship(); for ZODB3, just hang them off 
>>the root with suitably unique keys.)
>
>One thing that perhaps wasn't made clear is that the repository doesn't 
>directly contain relationships.  It contains named relationship sets.  I 
>don't know if this is what you're talking about--correct me if I
misunderstood.

Um, what's a "named relationship set"?  That's not an entity that I recall 
seeing named in the proposal.



>>2. There is no directionality to the associations; this doesn't work for 
>>hierarchies or graphs.  E.g. think 'parent_child = Relationship()'.
>>That won't work.
>
>I have that concern also, although it was only a gut feeling until 
>now.  Elaborating on your example, an object may participate in multiple 
>parent/child relationships, sometimes as a parent, sometimes as a 
>child.  With the current API, you can't distinguish between the parents 
>and the children.  That certainly won't work, and I'm sure it's only one 
>example of needing directionality.

Here's another one: supervisor->staff member.  It's not a containment 
relationship (I don't *contain* my staff!) and "supervisor" is not a 
different class of object (since managers have managers).  Therefore, for 
any given supervisor->staff link, it's impossible to tell who is the 
supervisor and who the supervisee, without directed links.  While this may 
be quite egalitarian, there are many businesses where such a model doesn't 
work very well.  ;)



>>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'.
>
>That is an excellent idea if we can determine that this project is 
>distinct from the Zope 3 relationship service.  It feels like the two 
>projects are aiming to solve largely the same problem, but if they aren't, 
>a name change will help clarify the difference.

Maybe it's a pluggable *implementation* of a Z3 relationship service.  :)


_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev at zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev