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

[Phillip J. Eby]

At 08:19 PM 5/9/03 +0200, Roché Compaan wrote:

>This model seems like a perfect fit for what we want to achieve. I read
>through the chapter on associations in the MOF specification but found
>it quite terse and assumes some knowledge that I don't have.

Hm.  Perhaps we're not looking at the same specification.  Are you talking 
about the section titled "Semantics of Associations", about 4 pages long, 
that includes a subsection called "A mathematical model of association state"?

By the way, keep in mind I'm not proposing that you adopt MOF's formal 
semantics.  But I think that what you guys are trying to design could 
perhaps be defined as a strict subset of the MOF Association concepts 
(which in turn are a strict subset of the UML Association concepts).


>If one takes the course teacher relationship from the API then I suppose
>one would have an association instance with two association ends named
>course and teacher.

Yes.  An M1-level association instance.


>  If we say that a course has only one teacher then
>the association end named course will have a cardinality of one and
>teacher will have a cardinality of many (I don't think the term
>multiplicity will work here - it looks like it has fixed upper and lower
>bounds. Or can you have a N multiplicity?)

You can have an "unbounded" upper limit of multiplicity.  Typically this is 
implemented using -1 to mean an unlimited multiplicity.  Multiplicity in 
the MOF is defined as a structure with the following fields:

class MultiplicityType(model.Struct):

     class lower(model.structField):
         referencedType = model.Integer

     class upper(model.structField):
         referencedType = model.UnlimitedInteger

     class isOrdered(model.structField):
         referencedType = model.Boolean

     class isUnique(model.structField):
         referencedType = model.Boolean


And an AssociationEnd is defined as:


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


(AggregationKind is an enumeration of "none", "shared", or "composite".)


>What attribute on the association determines the direction?

There are two directions to any association, but they may not both be 
navigable (see the 'isNavigable' field for association ends).  If an end is 
navigable, then you may go from that end to the other.  If an end is 
changeable, then you may create or destroy links from that end.

Note that an AssociationEnd is not the same as your RelationshipView 
descriptor.  The thing that corresponds to RelationshipView is called a 
Reference in the MOF.  A Reference "exposes" an AssociationEnd as a feature 
of a class.

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)



> > 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.
> >
>
>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.