On Fri, 2003-05-09 at 05:28, Roché Compaan wrote:
On Thu, 08 May 2003 19:58:22 -0400 "Phillip J. Eby" <pje@telecommunity.com> 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.)
2. There is no directionality to the associations; this doesn't work for hierarchies or graphs. E.g. think 'parent_child = Relationship()'. That won't work.
What we have at the moment is a graph and strictly speaking a graph has no direction in its edges (maybe you meant directed graph). As far as I can see graphs are possible, hierarchies are not. Can't one just use containment to represent hierarchies? If one can what other use cases are there for directionality in associations?
Dependency: - Object 'foo' dependsd on object 'bar'. Asymmetric business associations - Jane is the boss of Fred. - Invoice line items decrement the stock count of SKU items. etc. I would argue that symmetric (undirected) graphs are much less common in business applications than asymmetric ones.
All in all, I don't see any reason to make this part of ZODB's API or add special repositories to support it. However, like PersistentDict or BTree, relationships might be a nice tool to have available in the ZODB library.
+1 to that. I guess I can't figure out what the ZODB has to do with relationships.
A final comment... Once this takes directionality into consideration, you might consider calling it an 'Association' rather than a 'Relationship', as it would then largely meet the MOF and UML semantics of an "Association". That is, an association is a collection of directed links between objects. It would then make sense to refer to refer to the 'RelationshipView' as an 'AssociationEnd'.
We used the term Relationship because the proposal is based on the entity-relationship model. I am not too familiar with MOF so maybe you can explain how it will apply to the current proposal. Thanks for your comments Phillip. I was hoping you say something because you must have thought about this when designing PEAK.
E-R models derive largely from the RDBMS world; UML class models are not completely isomorphic with them, but might be a better fit for the kind of thing you are thinking about (for instance, E-R models generated from class models often show weird "extra" tables to capture the oddities of mxn relationships). Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com