Phillip J. Eby wrote:
At 11:07 PM 5/8/03 +0200, roche@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.
Issues:
1. "Global relationship repository" has no use cases, and smells like trouble. Why not just explicitly store the Relationship() somewhere? After all, every RelationshipView will have a reference to it. (For ZODB4, a persistent module might be the natural place to put the "official" reference to the Relationship(); for ZODB3, just hang them off the root with suitably unique keys.)
First, I also think it should be possible to have more than one relationship. On argument for that is complexity of searches, another is virtual hosting and managability (import/export). Additionaly, why should relationship repositories just hang down the root and have unique ids? Maybe this is Zope3 related (which I don't know much about), but in zope2, it might be nice to use the acquisition machinery in discovering relationship storages. Example: You want to create amazon2. Your products are stored in a folder hierachy. books science philosopy mathematics CS OO Python Zope Twisted ... Java Websphere ... C++ C# Producural C ... ... etc. You want to implement something like "People who were interested in <spam> also were interested in <eggs>" - but on every level of the hierachy, i.e. (Zope, Twisted) in the deepest, one above (Python, Java) etc. Now, wouldn't the most natural and economic way to do that to put a RelationshipStorage in every level? Even if we consider the case that we'd like to store Relationships crossing hierachies, e.g. (Zope,Websphere), they'd be stored in the Relationship Storage which an ancestor of both of the objects to be stored, i.e. the one lying under OO. cheers, oliver