[ZODB-Dev] revise transaction API

[Christian Robottom Reis]

On Tue, Mar 30, 2004 at 10:25:44AM -0500, Jeremy Hylton wrote:
> >     - It would be nice to see the equivalent of savepoint in 3.3.. 
> 
> since commit(1) and abort(1) should be functionally equivalent, I don't
> think we'll get savepoints in 3.3.

Are they indeed functionally equivalent, though? The point I was trying
to make is that commit(1) and abort(1) are "single-step savepoints".
IOW, you can't have a chain of commit(1)s and abort(1) to the
intermediate steps -- abort(1) reverts to the point indicated by the
last commit(1) mark, and multiple calls to abort(1) after that are
effectively NOPs.

Having real, multiple savepoints would be a great feature and would
allow longer-running transactions a lot more flexibility in what sort of
manipulation they can do on their objects. A wizard-style UI is a good
usecase for this feature: you'd like to be able to undo changes as the
user moved back, and you can't really commit()/abort() the entire
transaction without risking "logical corruption" in your application.

> > The three features which we *really* miss in the ZODB, and which
> > influence the way we write applications significantly, are, in order of
> > importance:
> > 
> >     1. savepoints,
> >     2. partial invalidations (something like a partial sync() where only
> >        a subset of the objects are invalidated, without modifying the
> >        other objects in the transaction),
> >     3. getting all modified objects (inclusing those in subtransactions).
> > 
> > I don't see anything like 2. accounted for in the text, but I'm not sure
> > if it's relevant here , and if it is, how it would fit in to the
> > proposed APIs.
> 
> The problem with partial invalidations is that they provide an
> inconsistent snapshot of the database state.  In other words, we used to
> provide partial invalidations before we implemented atomic invalidations
> ;-).  It lead to corrupted databases.

I once posted a proposal for having "change groups" that would be more
or less "isolated transactions" where one added the objects to
transactions explicitly. This might allow for better control between
them, but I have never stopped to think about the underlying
implications that this model would imply.

Take care,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331