[ZODB-Dev] SQL persistence based on ZODB4 Persistence/Transaction packages

Phillip J. Eby pje@telecommunity.com
Sat, 29 Jun 2002 12:21:45 -0500


I'm currently working on a design for doing persistence to/from arbitrary 
databases (but primarily SQL, and secondarily LDAP) using ZODB4's 
Persistence and Transaction packages (ignoring the 'ZODB' package).  This 
persistence layer is for PEAK, the Python Enterprise Application Kit 
("TransWarp in a business suit"), and is intended to support pretty much 
arbitrary underlying database formats.

The detailed design is not finished yet, but I've got the big picture quite 
clear at the moment, based on a "shelf" full of "jars" which implement 
Transaction.IDataManager and Persistence.IPersistentDataManager, and using 
the existing ZODB4 cPersistence API and base classes.

I was skimming through the archives of this list, looking for helpful 
information or news, and noticed a mention of changing API's.  Can anybody 
say more about the planned direction of those changes, or perhaps point me 
to some documents or persons with the info?  I'd like to make sure I'm not 
basing my design work on invalid premises about how things will be 
structured.  Are we talking about major changes at the Python level, or 
just stuff that affects C extensions?  (I don't expect to have any C 
extensions of any consequence, at least initially.)  Any information would 
be helpful.

On a related note, I've noticed that the ZODB4 cache manages its own weak 
references, but it doesn't seem to do anything outside of the gc methods 
that weakref.WeakValueDict doesn't.  Perhaps it would be simpler to just 
subclass WeakValueDict?  You could still keep the '__active' dictionary, 
but just treat it as a set of keys, rather than as a 
dictionary.  __delitem__ would need to remove the key from __active, if it 
existed, __setitem__ would still need to check the state, and setstate() 
would just do a __setitem__, but I think that's about it.  Then you 
wouldn't need to move things from __ghosts to __active and back, and check 
both dictionaries on lookup operations.  The get(), __len__(), and 
__getitem__() methods and the _dictdel class would disappear altogether, 
some of the other methods would get shorter, and lookup performance should 
improve, assuming that one lookup in a larger dictionary is faster than two 
lookups in smaller ones plus some intervening Python logic.

But I actually originally meant to talk about the caching API, not its 
implementation.  :)  Specifically, I'm wondering if there's anything in 
ICache or Cache that is depended on by anything else in the Persistence 
package, or if it's really there for the benefit of the ZODB package.  I 
expect my persistence machinery to have rather different caching needs, so 
I don't plan to be implementing ICache (or even using the Cache 
implementation of it) for most of the caches in the framework.  Mostly, 
I'll be using either straight-up WeakValueDict or very slight modifications 
thereof, and occasionally dictionaries that get cleared at transaction 
boundaries.  (So you can see how I drifted off-topic above...)  Anyway, I 
just wanted to make sure, once again, that I wasn't planning to do Very Bad 
Things in the light of the now and future ZODB4.

Any info that anyone could share would be appreciated.  Thanks!