[Zope-dev] Experiments with ORMapping

[ender]

Hello,

i want to thank DC (jim, shane, and paul) for inviting me to come to the new 
DC offices. i had a great time and learned a bunch... and met 
the BFDL.

i gave a quick overview of the smartobjects design/framework and  jim and 
shane presented some ideas for an or mapping for the zodb.

to be honest it seemed both extremely elegant and slightly disturbing at the 
sametime. I've grown accustomed to treating the ZODB as a magic black box, 
that just works. integrating an or layer at this low level disturbs me as it 
meant that application developers would need to tinker at the lowest level of 
the zope framework, plus the dangers that to properly support application 
development the zodb would need to be bloated with accessory apis. at the 
same time it offers a really elegant way to make the or mapping available to 
python programmers on a pure python level (which is something i'm also 
interested in). 

for both approaches there are some similiar problems that must be tackled, 
namely definition of the or mapping, generation of stub python classes, 
integration with zope notions (permission, etc). so hopefully discussion here 
will flesh out, to the point of making a choice clear.

i'm primarily focused on doing the or mapping definition in xml, as its 
language neutral and allows me to leverage other tools (like torque 
java.apache.org/turbine/torque.html) to assist in application 
development/porting.

i've thought about it for a few days, and while i'm not convinced completely
that a zodb approach is the best method, i'm going to start work on the some 
of the support classes nesc. for moving forward, namely some of  the xml 
model/generators outlined in my design (embryonic)
(http://www.zope.org/Members/k_vertigo/smartobjects)

most of my concerns echo the issues that philip has brought up re the 
need of application developers. i do feel some if not most of these issues
can be solved, i'm just wondering if for zope this is the best solution. for
pure python development it seems alright. for zope, i wonder if a higher 
level application framework is more suitable. 

to clarify some existing points in this thread to date.

- (IMO) zpatterns is about two things, delegation and data abstraction at
the application level. the zpatterns framework doesn't assist in automating
this and its up to the integrator/developer to manually wire together all the 
app/business objects. the smartobjects framework is about automating
development and presenting easier development interfaces for both 
developers and designers. this isn't to say that such automation and 
interfaces couldn't be built on top of zpatterns, just to say that there are 
some different design goals. 

- one of the primary goals of smartobjects is easy integration with zope in a
manner that is natural for zope developers. this does not mandate a new db 
access api, its about facilitating automation of this api so that the objects 
can be treated as normaly zope objects. both approaches (smartobjects and or 
zodb) must still tackle similiar fundamental issues to integrate with zope. 
on the zodb level this seems complicated to me (which betrays my incomplete 
understanding of the zodb internals), plus it requires some additions to the 
zodb interface to allow effective application usage (namely a generic query 
mechanism, and probably interogation of a class information). 

- one of my main objectives in developing an or mapping is to use the
acs4 (www.arsdigita.com) applications natively (or as close as possible) 
within zope.

- my smartobjects design (www.zope.org/Members/k_vertigo/smartobjects) is
mine, in that smartobjects is primarily a iuveno project this does not mean 
it is smartobjects. stephen richter (of iuveno) liked parts of the design and 
will likely use it parts of it in a iuveno implementation but what comes out 
of iuveno is not limited or beholden in anyway by my proposal. the key focus 
of the proposal is a metamodel (schema) based approach.

questions

- i think any integration of or layer should be complementary to the zope 
framework. shane's existing examples and discussion of an or layer seem to be 
more geared towards replacing the zodb, than complementing. is the idea to 
use some sort of zodb product as a mounted storage?, or is this a replacement 
strategy.

cheers

kapil