[ZODB-Dev] SQL/ZODB integration (was Re: ZODB and new styleclasses?)

Shane Hathaway shane@zope.com
Mon, 01 Jul 2002 13:24:46 -0400


Phillip J. Eby wrote:
> For what it's worth, I've successfully designed (and have started 
> implementing) a comprehensive framework for SQL/LDAP/anything-backed 
> persistence using the ZODB Persistence and Transaction 
> packages/interfaces exactly as they are now, so I'm not sure how much 
> refactoring is really required.  ;)

Also FWIW, I've been working on something very similar for the O'Reilly 
open source conference.  The goal was transparent persistence to 
anything, SQL in particular, reusing as much of ZODB as possible.  I 
started by leveraging only persistence and transactions, but in the 
latest iteration, I was able to reuse most of the ZODB Connection (jar) 
and DB classes as well.

I used ZODB 3 / Zope 2 to avoid depending on a moving target, but it 
should be easy to move to ZODB 4 when it's ripe.  I have a working 
product that lets you "mount" a SQL database, file system, or some 
combination thereof.  And it can theoretically work over ZEO.  I have a 
high level screenshot demo in a slide presentation.

Don't slow down on my account, though.  You have ideas I can use, and 
maybe I have a few of my own.  I was impressed by the notion that you 
may be building the Python equivalent of J2EE.  And you've written a lot 
more words (English words ;-) ) than I have.

The latest thing I'm trying to work out is conflict detection.  Make 
sure you have some kind of answer for that.  If the Python app fetches 
some objects from the database, then an external application writes to 
the database, then the Python app tries to persist some changes that 
would conflict with the external application's changes, a ConflictError 
must be raised.  My current implementation ignorantly stomps on the 
other app's changes. :-)  You can avoid this by just declaring that 
external apps are not allowed to write to tables that the Python app 
writes to.  But in my case, I think that's not enough.

Shane