[ZODB-Dev] ZODB4 project plan

[Pieter Nagel]

On Thu, Nov 28, 2002 at 07:03:50PM -0500, Phillip J. Eby wrote:

> If it's not the transaction system itself that you're testing, why not just 
> abort the "inner" transactions, and don't bother having an "outer" 
> one?  Just curious.

Because of the things one wants to test is whether components commit
or abort when they are supposed to; and yet retain the ability to rollback
one's test database to a clean slate at the end of the test by aborting
the outer transaction.

This scheme presupposes a slightly different transaction API: when one
begins a transaction, the transaction may wind up either being an outer
transaction, or, if an outer transaction is already open, a new
subtransaction is opened. One can easily build this on top of the current
ZODB API.

This ensures that the tested components end up commiting and aborting
"real" transactions when the are used in production code.

This kind of API also simplifies the style of programming holger krekel
wrote about earlier in the thread:

> Maybe it's just me but i like to move into a programming paradigm where i 
> can write a "Component" which opens its own transaction regardless if it is 
> part of a outer transaction or not.
...
> An example. In a massive multiplayer universe i have lots of logics
> how the objects in this world interoperate.  Some components determine
> the outcome of local or wide-area fights, others implement 'research development' 
> and so on.  If the 'local fight' component detects a problem then it
> should be able to rollback to a consistent state (it may already have
> modified some objects in its substransaction).  It shouldn't be forced
> to care about other transactions it is also part of.  When and how to
> persist the game state seems like an (almost) orthogonal issue to me.  

-- 
     ,_
     /_)              /| /
    /   i e t e r    / |/ a g e l
    http://www.nagel.co.za