[ZODB-Dev] PROPOSAL: ZODB Relationships

[Shane Hathaway]

Jeremy Hylton wrote:
> 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?

That sounds right.  This will work in systems that do not require 
context wrapping.

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

Well... like we discussed in person, we shouldn't use the objects 
involved in a relationship as dictionary keys.  The keys should be some 
kind of identifier.  The right kind of identifier depends on the 
framework you're using: in pure Python, id(obj) serves as a reasonable 
identifier; in pure ZODB, obj._p_oid is better; in Zope 2, a tuple of 
strings is better; and in Zope 3, the best identifier is a hub ID.

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

Both Roche and I would like to follow PJE's suggestion and call these 
things UML-like associations instead of relationships.  So we'll be able 
to talk about "association ends".

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

That's good to know.

FWIW, it just occurred to me that these associations might be used to 
enforce ZODB integrity constraints.  Associations could provide the 
consistency requirement for ACID.

Shane