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

[Chris McDonough]

On Nov 8, 2007, at 9:14 AM, Jim Fulton wrote:
>>  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.
>>      """
>
> Why not subclass TransactionError?

It didn't before.  Should it?  There's also a DoomedTransaction  
exception in the interfaces package that could.
>>
>>  TransactionError.__bases__ += (POSError,)
>>  TransactionFailedError.__bases__ += (POSError,)
>
> Is this *really* necessary?  It's obviously a bit evil.  Let's  
> explore alternatives to this:
>
> 1. Just don't do it.  I'd be a bit surprised if there was code  
> actually catching POSError.

Me too; +1.  If I notice anything relying on them inheriting from  
POSError, I'll move POSError into the transaction module.

>> - 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.
>
> I'd rather not do this.  Let's be a bit more selective here.  The  
> number of imports from ZODB are pretty limited. Many of them should  
> move to transaction.  Some of them are just test utilities that can  
> be duplicated.
>
> I think the biggest challenge is WeakSet.  This could be broken out  
> into a separate package, but I think it's not as general as its name  
> implies and should probably just be moved to transaction.

OK.

>>  And I'm thinking that the transaction distribution should be named  
>> just "transaction".
>
> Yes, unless we decide to move the package.  I think transaction is a  
> bit presumptuous. :)

How about "zope.transaction"?  There's a good deal of 3rd-party code  
that does "import transaction" but we could supply a module alias for  
this purpose.  We'd just change the Z2 and Z3 appserver distributions  
to do "import zope.transaction as transaction" or whatever, and have  
the appserver distributions depend on a shim "transaction" module or  
module alias or whatever too so 3rd-party code would continue to work,  
maybe making imports using them issue a deprecation warning?

- C