[Z3-sqlos] RFC: Transaction simplification branch

[Brian Sutherland]

On Thu, Dec 08, 2005 at 09:42:48PM -0200, Sidnei da Silva wrote:
> It looks like a lot of changes indeed, and from the description they
> seem very sane.

Yeah, after the first one everything just started to unravel.

There are 3 un-resolved issues:

 * Why do we expire objects in a successful transaction? I can't think
   of a reason why we need to.
 * Why is expireSQLObject (the old expired event) so complex???
 * expireSQLObeject must never generate any SQL. I'm pretty sure it does...

> The only two issues that I can recall that need
> testing are:

Is this test rigorous enough for what you mean?
http://codespeak.net/svn/z3/sqlos/trunk/src/sqlos/ftests/test_transaction.py

> 1. changes that are not commited (eg, abort() was called) shouldn't
>    live past transaction boundaries. need to be specially carefull
>    about changes that stick on the cache. if I recall that's the
>    reason syncUpdate was called.

For an aborting transaction this is how it goes now:

    1 sync is not called on any object (this absence is tested)
    2 expireSQLObject is called on all dirty SQLObjects
    2 if any SQL was generated, rollback is called on the SQL connection
      via zope.app.rdb

> 2. all changes done must be successfully commited at commit().

For a committing transaction this is what happens:

    1 sync is called on all dirty objects
    2 expireSQLObject is called on all dirty SQLObjects
    2 if any SQL was generated, commit is called on the SQL connection
      via zope.app.rdb

-- 
Brian Sutherland

Metropolis - "it's the first movie with a robot. And she's a woman.
              And she's EVIL!!"