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