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]