Max M wrote:
- Developers should have the *option* of using relationships directly in their classes, with a Pythonic API.
I think that should be working on top a general relationship service.
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.)
I listed other requirements this morning, and as far as I can tell, few are fulfilled by mxmRelations. On the other hand, maybe I misunderstand mxmRelations. Does it fulfill the requirements I listed? I'm sure there's nothing wrong with mxmRelations, but it seems like we're targetting different audiences.
Let me say that I am not married to mxmRelations, and I am not trying to push it as a solution. But I think it has a sound model for relationships. One that is very general and expandable.
Ok, I'll take a look.
# perhaps a method on ZODB to return the RelationshipsManager ? rm = ZODB().getRelationshipsManager() rm.addRelationsships('members_groups', ManyToMany('members_groups')) r = rm.getRelationsships('members_groups') r.relate(someNewMember, someGroup) groups = r.get(someMember) >>> [someGroup]
We shouldn't add a getRelationshipsManager() method to any ZODB classes. In pure-ZODB mode, a possible way to store relationships is the use of a special branch of the ZODB root object. In Zope, there are normally two branches of the root object, "Application" and "ZGlobals". Relationship management could use a private branch, perhaps called "Relationships". But the application should not have to know that at all; it should never access self._p_jar.root()['Relationships']. That should be abstracted away. Shane