[ZODB-Dev] breaking out the transaction module from ZODB

Chris McDonough chrism at plope.com
Wed Nov 7 23:38:19 EST 2007


I've begun work on breaking out the transaction module so it can be  
used independently from ZODB.

Here's what I've done so far:

- I've moved TransactionError and TransactionFailedError from  
ZODB.POSException into transaction.interfaces, e.g.:

   class TransactionError(Exception):
       """An error occurred due to normal transaction processing."""

   class TransactionFailedError(Exception):
       """Cannot perform an operation on a transaction that previously  
failed.

       An attempt was made to commit a transaction, or to join a  
transaction,
       but this transaction previously raised an exception during an  
attempt
       to commit it.  The transaction must be explicitly aborted,  
either by
       invoking abort() on the transaction, or begin() on its  
transaction
       manager.
       """

- I've caused ZODB.POSException to add the POSError base class to both  
TransactionError and TransactionFailedError
   after importing them from transaction.interfaces, e.g.:

   from transaction.interfaces import TransactionError
   from transaction.interfaces import TransactionFailedError

   # We want to be able to distribute the transaction module independent
   # from ZODB but we need to maintain backwards compatibility with  
older
   # ZODB releases, where TransactionError and TransactionFailedError
   # were actually defined within ZODB.POSException, and inherited from
   # POSError.  With this solution, if ZODB is present, TransactionError
   # and TransactionFailedError will have POSError as a base class.  If
   # ZODB is not present, they won't.  Thanks to Ian Bicking for
   # suggesting this solution; as ugly as it is, it does the job.

   TransactionError.__bases__ += (POSError,)
   TransactionFailedError.__bases__ += (POSError,)

- I've created a zc.zodbutils package that is essentially the code  
that currently lives in
   the ZODB.utils module; I've also moved the TimeStamp.c code that  
currently lives
   in 'persistent' into it.  A stub ZODB.utils module exists that just  
does
   "from zc.zodbutils import *", and in the persistent package's  
__init__.py, I
   do "from zc.zodbutils import TimeStamp" for backwards compatibility.

The intention is that the "transaction" distribution will depend only  
on zc.zodbutils (as will of course the ZODB distro, along with its  
other current dependencies plus the transaction distribution).  I'm  
wondering about version numbering and naming for the separate  
packages.. I suspect we shouldn't try to marry the transaction  
distribution version number to the ZODB distribution version number  
because they really won't be tied together that way.  Maybe just start  
transaction at "1.0" or something.  And I'm thinking that the  
transaction distribution should be named just "transaction".  And the  
name "zc.zodbutils" is just a placeholder, suggestions from interested  
parties would be helpful.

I haven't adjusted any imports in tests, nor have I repackaged the  
transaction module using setuptools yet.  I wanted to get a sense of  
whether folks thought what I've done so far is reasonable or if you  
might have done it differently.

- C



More information about the ZODB-Dev mailing list