[Persistence-sig] 'cucumber'

[Titus Brown]

->   TB> Hi everyone, I thought I'd toss my own little package into the
->   TB> fray.  I've written a fairly simple O/R mapping system named
->   TB> 'cucumber' that sits on top of PostgreSQL.  By making use of
->   TB> PG's inheritance hierarchies, cucumber class inheritance
->   TB> relations can be mapped directly into PostgreSQL in a very
->   TB> simple and transparent way.
-> 
-> Thanks for telling us about your system.  I don't know if there's much
-> fray here at the moment <wink>.  People seem to be busier working than
-> chatting about persistent.

What a shame <grin>.

-> How do you see cucumber fitting into the SIG's goal of generic Python
-> APIs for transactions and persistence?  I haven't had a chance to look
-> at cucumber, so I don't know what its implementation looks like.  Do
-> the ZODB4-based APIs discussed earlier look reasonable to you?

I'm having trouble following the ZODB-based discussion, because I don't
understand where y'all are coming from; I've never used either Zope or
the standalone ZODB distribution, partly because I would prefer to use
databases that are accessible across languages.  I have also not been
on the list for very long & haven't been able to read through all of
the archives in the detail they require.

cucumber by itself is not particularly important -- it's nice and simple
and useful and all that, but a bit too odd to be widely adopted -- but
I'd like to see if it can be fit nicely into whatever transaction & (data)
persistence APIs are produced.  I think cucumber (or, rather, PostgreSQL,
but with the cucumber adaptor layer) provides a nice example of
what a minimal persistence and transaction API should be able to encompass;
if the APIs produced are significantly more complicated than required for
cucumber, I'd argue that perhaps this SIG is making things too complex.

As I'm sure you all know, PostgreSQL provides a simple ACID-compliant
SQL database with commit & rollback.  The main thing I've been confused
about in the discussions so far is how exactly savepoints work -- they
seem to be a bit more complicated than normal transactions -- and
whether or not they'll be a necessary part of the final product.

Other than that, I'll happily lurk until I feel I have something to
contribute ;).

cheers,
--titus