[Zope-dev] OR mapping proposal

[Shane Hathaway]

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