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

[Phillip J. Eby]

At 12:22 PM 5/10/03 +0200, Roché Compaan wrote:
> >
> > class AssociationEnd(TypedElement):
> >
> >      class multiplicity(model.Attribute):
> >          referencedType = MultiplicityType
> >
> >      class aggregation(model.Attribute):
> >          referencedType = AggregationKind
> >
> >      class isNavigable(model.Attribute):
> >          referencedType = model.Boolean
> >          defaultValue = True
> >
> >      class isChangeable(model.Attribute):
> >          referencedType = model.Boolean
> >          defaultValue = True
> >
>
>Seeing it in Python brings the concepts home :-)

There is a structurally complete M2-level implementation of MOF 1.3.1 in 
Python at:

http://cvs.eby-sarna.com/PEAK/src/peak/metamodels/MOF131.py?rev=HEAD&content-type=text/vnd.viewcvs-markup

if you want to see the whole thing.  It is not behaviorally complete; i.e. 
it does not do model verification or check any of the MOF-defined 
constraints.  But it shows all of the structure of the MOF metadata.


> > (AggregationKind is an enumeration of "none", "shared", or "composite".)
>
>The chapter about Aggregation Semantics didn't help me much, but I have
>a feeling that we don't need it now?

Probably not.  In my experience, aggregation metadata is something that's 
generally only needed at the M2 level: tools that work with metadata.  For 
example, a tool that is generating code for the association, or one that is 
serializing objects that participate in the association.  (E.g. the XMI 
format for serializing objects to XML uses aggregation metadata to 
determine whether associated objects are nested or placed side-by-side.)


> > So for a teacher-teaches-course association, we might say something 
> like this:
> >
> > teacher = AssociationEnd(multiplicity=(1,1))
> > courses = AssociationEnd(multiplicity=(1,None))  # if we use None for 
> unbounded
> > Teaches = Association(teacher, courses)
> >
> > teaches.add(aTeacher,aCourse)
> >
> > aTeacher = Teaches.teacher.get(aCourse)
> > hisCourses = Teaches.courses.get(theTeacher)
> >
> >
> > class Teacher:
> >      courses = Reference(Teaches.course)
> >
> > class Course:
> >      teacher = Reference(Teaches.teacher)
>
>This makes me feel much more comfortable than the current proposal does.
>Are the following changes in order:
>
>     We replace the Relationship class with Association and introduce an
>     AssociationEnd class.
>
>     We rename the RelationshipView descriptor to Reference.

Pretty much.  The interfaces of each of those items will still need 
refinement, I think.


> > >So instead of storing both entries in course_teachers we store an entry
> > >in course_to_teacher and an entry in teacher_to_course?
> >
> > Essentially.  You could actually do this by having the AssociationEnds
> > implement each direction of the mapping.  A non-navigable end, of course,
> > would not need such a mapping.
>
>I am going to work out some of these concepts in code now - nothing
>formal about it yet, its just the way my brain works. I'l report back :-)
>
>I asked Sean Upton as well since he brought it up, but do you have any
>thoughts on how metadata about the association should be implemented?

That depends on what you consider "metadata".  :)  What did you have in 
mind?  The MOF131 module I referenced is a "metadata" model for everything 
in MOF, including association, end, and reference.  But I'm not sure that's 
what you're talking about.