[ZODB-Dev] PROPOSAL: ZODB Relationships

[roche at upfrontsystems.co.za]

* Jeremy Hylton <jeremy at zope.com> [2003-05-09 19:27]:
> On Thu, 2003-05-08 at 17:07, roche at upfrontsystems.co.za wrote:
> > We finally have a proposal out for ZODB relationships. This proposal
> > presents an API for relationships, summarises ideas and contributions
> > from a lot of people and was fuelled by the recent discussions about
> > relationships on Zope3-dev and Zope-dev.
> > 
> >     http://www.zope.org/Members/upfront/ZODBRelationships
> > 
> > Your comments would be appreciated.
> 
> I have a few suggestions about the "providing objects with views of
> relationships" section.  
> 
> My personal interest is in objects that store the relationships
> internally rather than in an external data structure.  This seems like a
> natural structure for a ZODB application, because it keeps the
> references local to the objects involved; you don't need to load some
> external objects to access the relationship.  This isn't the right
> approach for all applications, but I think it's useful in many cases.
> 
> How do we implement this given the current proposal?  I suppose that
> there is more than one kind of Relationship object.  An implementation
> that provides its own storage must be reachable from the database root
> explicitly.  An implementation that stores relationships on the objects
> is only used at runtime to associate storage with other persistent
> objects.  Is that right?  

There seems be a lot of good reasons not have a global relationship
repository and to be explicit about where the relationship instance is
created. If we drop the idea of global relationship repository then it
should be possible to bind the Relationship instance to the class
itself.

> The proposal should clarfy how implementations might reasonably store
> the relationships.  If an implementation uses a BTree, it would be
> necessary for the objects in the relationship to be totally ordered.  If
> the implementation uses a dictionary, then they would need to define an
> __cmp__() and an __hash__() or neither.  It might be useful if the user
> could provide a hint to the implementation about what is acceptable for
> these objects.

Can you elaborate? 

An area where I thought where the user should have more say is in the
return value of a RelationshipView with multiple cardinality. When I
reference student.courses should the return value be a sequence or a
dictionary. I can imagine cases where either would work.

> I would like to see a different approach for specifying cardinality,
> because there are really only two possible values -- "single" and
> "multiple."  (Might one and many be more consistent with the typical
> jargon?)  Rather than specifying a magic string as a keyword argument,
> why don't we have to different RelationshipView classes?
> 
> I think the word "View" is probably carries too much baggage in Zope. 
> I'd rather find another word for the "end" of the relationship.

I think the MOF model mentioned by Phillip will lift as from our
terminology mudslide ;-)

> 
> I also wanted to comment on the risk factors.  I think the
> implementation should start in ZODB4, where it would actually be part of
> the persistence package.  We expect to migrate Zope 2.x to ZODB4
> sometime this summer, so I wouldn't worry too much about ZODB3 support.

Mmm, when is your summer?

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