[ZODB-Dev] revise transaction API

[Christian Robottom Reis]

On Tue, Mar 16, 2004 at 04:03:48PM -0500, Jeremy Hylton wrote:
> On Tue, 2004-03-16 at 15:27, Christian Robottom Reis wrote:
> > On Tue, Mar 16, 2004 at 03:21:22PM -0500, Jeremy Hylton wrote:
> > > We've been having some internal discussions about how to revise the
> > > transaction API for ZODB 3.3.  I posted a page in the ZODB Wiki that
> > 
> > I see this mentions savepoints for ZODB4. Can you tell me if you can
> > roll back to any savepoint in a running transaction's history? If so, it
> > would be a solution to that last (subtrasaction) problem I posted about.
> 
> I think it is just what you're looking for.  When you call savepoint(),
> you get an object with a rollback() method.  Anytime you call
> rollback(), you revert all changes made since the savepoint() call.

I don't think my box has enough memory for the number of +1s I'd want to
add here, then <wink>

Comments on http://zope.org/Wikis/ZODB/ReviseTransactionAPI

    - It may make sense to describe the setLocalTransaction issue in the
      =Current transaction= section. When setLocalTransaction is called,
      you effectively have one transaction per resource manager, which
      means the answer to "What is the current transaction?" is linked
      to the answer to "What is the current resource manager?"

    - Shouldn't the Extended transaction API describe ways to get the
      changes participating in the transaction? Something like
      get_modifications() (that might in the ZODB case return OIDs which
      are materialized by the resource manager)?

    - I don't have a [non-contrived] usecase for suspend/resume in my
      application set.

    - There's a question:

        (It's an error to modify an object when there is no transaction?)

      Isn't this sort of answered by the text in =Current transaction=?

         A particular manager could implement the policy that get()
         called before new() returns None or raises an exception.

      The way I see it the ZODB's default resource manager would specify
      this behaviour (and I think yes, it should complain).
    
    - "I like the ZODB 4 names and approach prepare()" -> do you mean "I
      like the ZODB 4 names approach() and prepare()"?

    - It would be nice to see the equivalent of savepoint in 3.3.. 

    - I don't quite get what the Third clause is for in =ZODB
      Connection and Transactions= -- in what situation would a
      Connection want to provide a specific resource manager?

    - Currently (in HEAD), if you close() the connection, modifying
      objects and manipulating transactions gets you a number of
      interesting exceptions raised. I had a patch that cleaned this up
      somewhat, but it was simplistic (and nobody commented on it)

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.

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