[PEAK] Re: ZODB4 in PEAK status

[Phillip J. Eby]

At 02:32 PM 1/12/04 -0600, Stephen Haberman wrote:
>Hi,
>
>I'm working on a small application in PEAK and am so far liking the
>experience. The peak.model stuff is great; it's where I started
>reading the PEAK source and adapting my small domain model to it,
>and am now branching out.
>
>So, I'm getting ready to write the persistence stuff and was
>wondering two things about the ZODB4 code in the PEAK CVS:
>
>1) Is it okay to use? Is anyone currently using it successfully?

If by that you mean the 'Persistent' base class, and the 'peak.storage' 
machinery that uses it, then a) yes,   and b) See the test suite.

On the other hand, if you mean "can I store peak.model stuff in a ZODB 
storage?", then a) it's not supported, and b) not as far as I know.


>I'm fine with it being alpha and having to play/hack around to get
>it working, I'm just wondering whether it's good alpha that pretty
>much works and will be improved or bad alpha that might/might not
>work and could be dropped (e.g. I saw the ZODB4 development stopped
>about 6 months ago to clean up ZODB3 and don't know how permanent
>this is and whether there are bad things about ZODB4 that were a
>factor in the decision).

Dunno about ZODB4.  But the long-term direction for PEAK is that even what 
little ZODB there is in PEAK will be dropped in favor of an approach that 
better integrates with peak.query (for data loading and saving) and 
peak.events (for GUI's and business rules).

Note that ZODB4 uses a *very* different transaction model than PEAK.  PEAK 
does not support subtransactions or nested transactions, but does support 
multiple "placeful" transactions per thread, while ZODB4 is pretty much the 
opposite.  PEAK supports an arbitrary number of "stacked" data managers, 
each with their own APIs.  ZODB has a uniform interface for data managers, 
and can't stack them in a transaction.  And so on and so on.

Really, the only point of compatibility between the two at all is the use 
of the Persistent base class, which has some rather annoying misfeatures 
for what PEAK wants to do with persistence, anyway.



>2) Does anyone have some sample code using ZODB4 (preferably, though
>not strictly, in PEAK)?

I guess you are actually talking about ZODB storages here.  See my comments 
above about the significant architectural incompatibilities between PEAK 
and ZODB wrt transactions and storage APIs.


>I haven't seen any examples on the site or in CVS and am just
>wondering if anyone has a project, e.g. in their personal or company
>(assuming the license is okay) CVS, I could glance through. Written
>tutorials/examples are great, but I'd be perfectly happy to just
>read through code.
>
>I'm fine with backing off ZODB4 and using something more traditional
>like sqlite. If this is the suggested route, I'd appreciate a
>confirmation of such. ZODB4 was just my first choice.

The ZODB architecture is really designed for "content" structures, with an 
open application architecture.  That is, one requiring an unlimited number 
of object types to be added, with arbitrary relationships, etc.  For PEAK's 
target audience, that's a very niche sort of application, and not the norm, 
which is a more "statically typed" application built on a corporate 
RDBMS.  (Which is why you'll find that the best-maintained DB drivers in 
PEAK are actually the Sybase and Oracle ones.)

So, just from where PEAK is coming from, no, I don't really recommend 
ZODB.  If I'm going to use flat files, I'd prefer them to be human readable 
(text, CSV, XML), rather than binary.