[Zope-dev] RFC: RelationAware class for relations betweenobjects

[Shane Hathaway]

Oliver Bleutgen wrote:
> Shane Hathaway wrote:
>> I agree.  It would be helpful, though, to identify a use case that 
>> describes why both you and I believe that relationships must be stored 
>> in a centralized location.  I'd like this to justify a particular 
>> implementation I'm considering (see below.)
> 
> 
> To add some perspective from the "outside", i.e. a Zope 2 product 
> developer, I really can't see why relationships should be stored this way.
> First, it feels so "un-objectoriented". If I want to know from an object 
> to which other objects it relates to (I am implying here that 
> relationships are directed), I want to ask the object, not some 
> centralized location.

Thank you for your perspective.  This gives me an opportunity to 
elaborate more.

As Steve said, it is advantageous to store relationships in a central 
location because it enables you to infer new relationships without 
traversing the object system.

But like you say, you need an object-oriented view of relationships. 
That is why descriptors (or in ZODB3, ComputedAttributes) are an 
essential requirement for the right relationship management solution. 
In a student registration system, to find out the current course 
registrations for a student, you'd like to simply use the expression 
"student.current_registrations".  To achieve this, current_registrations 
should be a descriptor or a computed attribute.  That way, it can 
transparently know where to find the relationship repository and which 
student to look for.  Thus relationship storage can be centralized 
without cluttering the application or burdening developers.

> Second, there's the point of scaling. Let's say I have an online shop 
> with 100 categories, and 10000 items for sale. Say I want to place items 
> in more than one category. I'd use relations (category -> item). But now 
> the central "relationship" database will hold up to one million items, 
> while storing the relationships in the categories will only go up to 
> 10000. And that is IMO the more typical use case.

We haven't chosen a relationship storage model yet.  That's the subject 
of my next email.

> While you can search the central location for relationships, the same 
> could also be achieved by combining the local storage of relationships 
> with maybe a special index for (Z)Catalog.
> 
> I also don't see how one could get an (A,B) relationship implemented in 
> Zope 2 without B being RelationshipAware (hah ;)), no matter where the 
> relationships are stored. Depending on the key used for B, a lot of 
> problems can occur. As it was talked about the problem with "moving" 
> objects, I assume the path to an object could be the used as a key. This 
> gets interesting when on deletes B and adds another B for instance.

This is why it's important to support (but not require) indirect 
references to objects.  In a pure ZODB application, it's probably 
simpler for relationships to make direct references to related objects. 
  In a Zope application (with context wrapping and a filesystem-like 
structure), it's better to make indirect references with the help of an 
object hub or similar.

> Another question, what happens if I export a subtree with objects to 
> another zope? With the relationships are stored as attributes to the 
> objects, I'm able to to at least keep some of the relationship 
> information, maybe I just have to verify which relations are still valid 
> and delete the ones which point to non-existing objects. What would I do 
> in the centralized case?

You would just export/import your relationships also.  If you use 
indirect references, all the relationships will remain intact.

> In short, as a developer for zope 2, I'd like to see relations 
> implemented in their most basic form, that is as a possibility to do a 
> 1:n mapping between one object and others.

Note that you already can.  ZODB is mature enough that it allows 
multiple references to a single object, so you could just tie two 
objects together in a relationship.  But there are numerous problems 
with doing that.  The requirements / use cases I listed earlier describe 
some of the problems that need to be solved.

Shane