[Zope-dev] OR mapping proposal

[Phillip J. Eby]

At 09:37 AM 5/15/01 -0400, Shane Hathaway wrote:
>http://dev.zope.org/Wikis/DevSite/Proposals/ORMappingDB
>
>Comments encouraged!
>

I see two themes here: an implementation-independent data management API,
and metadata.

May I suggest that perhaps a design effort focused specifically on these
three things, rather than on an object-relational effort per se, might be
more valuable to the community as a whole?  SmartObjects, ZPatterns, and
TransWarp could *all* benefit from community-wide standards for an
implementation-neutral data management API and a metadata system.  Right
now, these efforts are fragmented, and focused on different parts of the
puzzle.  SmartObjects is focused on permissions and UI aspects, while
TransWarp is aimed more at the structural metadata, and ZPatterns
specializes in implementation glue.

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.

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).

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.

[sent to list and Wiki]