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
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
