roche@upfrontsystems.co.za wrote:
There has been a lot of discussion about the need for a service that manages relations between objects on zope3-dev lately and in the past. I thought this would be a good time to share some code we have written to make relations a bit easier in Zope 2 and to invite some comments on it. The attached module provides a mixin class that collaborates with Max M's mxmRelations product almost like CatalogAwareness collaborates with the ZCatalog. I really hope that this can be an acceptable interim solution until relations are better managed by the ZODB or by some service in Zope 3.
I'm going to take this opportunity to move the discussion here instead of zope3-dev. Relations are important for any sizable application. That means to me that support for relations should not require the Zope application. It seems like relations shouldn't even require acquisition, context wrapping, or a component architecture. Currently, Zope 2 fulfills most needs for relations using ZCatalog, but ZCatalog is a lot to swallow. Jeremy posted some code that started to look like the right way to create relations in ZODB. http://mail.zope.org/pipermail/zope3-dev/2003-April/006720.html Here are the important features that made it interesting: - You describe relations in the same place you write classes. The great thing about an object-oriented database is that you can get so much done just by writing classes. But in the current ZODB, as soon as you need flexible relationships, you have to move into a totally different sphere, such as creating a ZCatalog or some kind of relationship service. It shouldn't be that way. Python is expressive enough. - Descriptors elegantly provide custom views on relations. In the example, "zope3.developers" looks like a set of Developer objects. - All the implementation details, such as use of BTrees, was moved away from the application code. To me, this means that the default relation implementation could be substituted depending on the capabilities of the storage method. Ape, for example, could implement relational queries by translating to SQL. Unfortunately, I didn't like Jeremy's revisions quite as much. The revised version creates two Relation objects instead of one. Maybe I just don't understand it yet, but it doesn't fit my brain. ;-) I prefer the notion of having two views on a single relation. I also feel that having a many2many function might be oversimplifying, since I came up with the need for a "many2many2many" function over the weekend. That would be wrong! We need to make sure the interface fits an existing, well-researched model for relationships. I only know about relational tables, topic maps, and RDF. Max M: your example is useful and probably more manageable than ZCatalogs. But I think it would be more useful if it provided an easy way to create relations in the code itself. You only have a comment that says the relation already exists. Jeremy's example creates the relation if it doesn't already exist, although it's only a basic relation. You example would also be enhanced by the use of descriptors. Roche: your example is purely implementation, although the ideas look interesting. Try writing something similar to Jeremy's example to evaluate the simplicity of your approach. The current Zope 3 plan is to put all relation management in a service. As I see it, that is one possible implementation of Jeremy's relation() function. Also, I would be a little disappointed if creating relations always required writing XML-based configuration documents or visiting something in the management interface. Instead, a little bit of Python code ought to be sufficient. Now, don't assume I really know what I'm talking about! I'm not a database administrator, and I'm evaluating the proposed ideas both objectively and subjectively. If nobody disagrees with me then I'll be afraid that nobody agrees, either. ;-) Shane