[ZODB-Dev] A different sort of ZODB backend

Phillip J. Eby pje@telecommunity.com
Wed, 20 Nov 2002 17:26:48 -0500


At 01:39 PM 11/20/02 -0500, Jeremy Hylton wrote:

>So there's a mismatch right now between what you want to do and where
>the responsibilities lie in ZODB.  It sounds like we'd need to create
>another pluggable layer that controls how ZODB serializes an object
>for storage.  I think this would be a good idea.  The implementation
>in ZODB4 is evolving so that all the serialization responsibility in
>one module.  It seems natural to make this pluggable.
>
>I would say that ZODB4 is stable enough to think about how to do this,
>but not to actually do it.  That is, ZODB4 is going to be evolving a
>lot in anticipation of an alpha release in December.  I'd be thrilled
>if soemone would tackle this project, but there implementation would
>probably have to change frequently to accomodate other interface
>changes.

FWIW, in PEAK I have a set of data manager base classes that can save or 
load to arbitrary storage formats when appropriately subclassed.  I'm using 
ZODB4's Persistence and Interface packages, but nothing else from 
ZODB4.  (PEAK has its own TransactionService framework for transactions.)

So far I have unit tests that handle saving and loading from a tabular 
RDBMS-style format, and loading from XMI format files.

The principal drawback of the current state of my work is that you have to 
manually write save() and load() methods for each data manager.  But this 
is also its greatest strength, since you can do pretty much anything in 
those methods.  I expect that as I use this code for real-world work, I'll 
evolve subclasses that use metadata to automatically implement 
object-relational mappings.  I'm just waiting to see what I'll actually need.