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

[Roché Compaan]

Hi Phillip

> >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"?

Aah, that section describes it much better. I must admit I didn't read
through the whole spec.

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

Yes, it is the concepts in the MOF model that fits - I just need to
understand it to apply it.

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

Seeing it in Python brings the concepts home :-)

> (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?

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

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.

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

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?

-- 
Roché Compaan
Upfront Systems                 http://www.upfrontsystems.co.za