[Z3-sqlos] RFC: Transaction simplification branch

[Sidnei da Silva]

On Fri, Dec 09, 2005 at 12:07:00AM +0100, Brian Sutherland wrote:
| Hi,
| 
| I just cut a new branch with some major simplifications to the
| transaction machinery of sqlos. But these are _big_, so I would like to
| ask for testing/comments before I go further.
| 
| Perhaps I went too far? Or cut something necessary?
| 
| The branch is at:
| http://codespeak.net/svn/z3/sqlos/branch/jinty-simplify-transactions
| 
| The main changes are:
| 
| * Call sync as a pre-commit hook.
|     (kudos to Jim, http://www.zope.org/Collectors/Zope3-dev/511)
| 
| * don't syncUpdate anymore on commit or sync on prepare
|   (It was already done in the pre-commit)
| 
| * Don't force the zope.app.rdb data manager to join the transaction.
|   (Thanks to the pre-commit hook this is not necessary)
| 
| * Rip out the testing support code in the transaction module and re-write
|   the unit test in a weaker but less brittle way. We test results now,
|   not process.
| 
| * Make self.objects self._objects.
| 
| * Rip out sanity checking code checking that the transaction manager
|   always dealt with the same transaction.
| 
| * The Transaction Manager doesn't take the sqlconnection as an argument
|   anymore as that has become un-necessary with the other changes.
| 
| * Get rid of the events module.
|     - The modified subscriber disappeared as we don't call it anymore.
|     - The expired event was hardwired into _transaction.py
| 
|     Rationale: When you are committing/aborting a transaction you don't
|     really want to be firing events. This makes it very easy for people
|     to hook in exception raising code which can make a serious mess of
|     things...
| 
|     Also it was just too many layers of confusion for what was needed.

It looks like a lot of changes indeed, and from the description they
seem very sane. The only two issues that I can recall that need
testing are:

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.

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

If that works, I'm happy.

-- 
Sidnei da Silva
Enfold Systems, LLC.
http://enfoldsystems.com