On Tue, 15 May 2001, Phillip J. Eby wrote:
If we had a standardized manipulation API or idioms (like JavaBeans) for application objects, then having lots of ways to *implement* storage would be a good thing. Different products and offerings could co-exist and compete in the storage implementation space, and users would have the benefits of being able to choose their back-ends and app frameworks without being locked into one framework's API.
That sounds useful, though I've been hinting at a more gradual approach. For example, I might define an OR mapping like this early on (roughly): class UserMapping (ObjectMappingScheme): def loadState(self, object, key, store, cursor): records = cursor.execute('select login, password from users' ' where uid=%(key)s', {'key': key}) d = object.__dict__ r = records[0] d['id'] = key d['login'] = r['login'] d['__'] = r['password'] def storeState(self, object, key, store, cursor, transaction): d = object.__dict__ cursor.execute('update users set login=%(id)s password=' '%(__)s where uid=%(id)s', d) Then I might see that many tables conform to a pattern and I would convert it to this: UserMapping = SimpleAttributeMapping(table='users', {'id':'uid', 'login':'login', '__':'password'}) Then I could make a web interface for creating SimpleAttributeMapping objects. Of course this is just the simplest case and things get more interesting when you have hierarchies of objects or complex queries.
Perhaps I should offer up a counter-proposal, focused on establishing a common API and proposing some of the requirements for same? Presumably we are all agreed that it should be as Pythonic as possible, but no more so. :) Also, API is perhaps not the right word, it is more about access and manipulation idioms. It needs to deal explicitly with the notion of relationships as well as "attributes" in the sense of data fields. And it needs to deal with the notion of how you determine what classes should be used for what things and how to get at those classes (since they may need to be backend-specific).
You mean a "complementary" proposal, don't you?
These are issues, by the way, which the current ZODB API dodges, and that is why I've been saying that doing O-R mapping in ZODB doesn't help the key issues of database independence. You *still* have to code to a style that is compatible with changing back-ends. I think it might be helpful if we all got on the same page about what that style should be, and then all these efforts could go forward knowing that in the Zope application space, users will only need to learn one such style at the Python level, and any education efforts about that style can be leveraged across many possible implementation approaches.
Sounds great! Shane