TransactionFailedError import error in storm.zope.zstorm

[Drew Smathers]

Tested with zope-3.3.1.

Importing TransactionFailedError from storm.zope.zstorm causes import error. According to internal documentation in transaction._transaction, TransactionFailedError and TransactionError are no longer imported at the top-level. Patching is easy, though a little hackish. I have added import directly from ZODB.POSException under _join:

    def _join(self, trans):
        # If the store is still alive and the transaction is in this thread.
        from ZODB.POSException import TransactionFailedError
        store = self._store_ref()
        ....

[Drew Smathers (djfroofy)]

Actually ... this problem is no longer occurring - but I've switched from standard zope instances to using zopeproject and trimmed my PYTHONPATH down to nothing. When and where this stopped breaking? - I'm embarrassed to admit I don't know ;).

So please mark this bug as irrelevant, unless you think it should be pursued further (I don't think it should). Sorry for the confusion.

[Gustavo Niemeyer (niemeyer)]

I'm glad to hear that it's working for you. I suspect it might be just an older
version of the transaction package.

In any case, thanks for you input on the subject.

[James Henstridge (jamesh)]

I ran into this bug with some Launchpad (we have not yet upgraded to a sufficiently new version of Launchpad).

Is there any reason to not just import this exception from ZODB.POSException in all cases? It will work with older versions of Zope and does not depend on the contents of a private module.

[Drew Smathers (djfroofy)]

Please also review my patch, since I had to defer the import - even importing ZODB.POSException at the module level was causing issues. In either case I think the zope developers need to find TransactionException a new home. It seems odd (and subject to XXX classification) in either case:

1. an `internal' module _transaction which shouldn't be referenced in external libs
2. ZODB which shouldn't contain things related to transactions that are not necessarily specific to ZODB

[James Henstridge (jamesh)]

I didn't have any problem importing from ZODB at the toplevel.

The comment in _transaction.py indicates that the problem was related to a circular import between ZODB and transaction which caused the import problem. As storm is outside of this import loop, I am surprised that you ran into a problem.

[Drew Smathers (djfroofy)]

Yes ... I forgot my original motivation for deferring the import. I've dug my old instance and retested - and indeed it does not fail will imported at the module level. My motivation was simply from a comment in the source code of _transaction which scared me:

# Sigh. In the maze of __init__.py's, ZODB.__init__.py takes 'get'
# out of transaction.__init__.py, in order to stuff the 'get_transaction'
# alias in __builtin__. So here in _transaction.py, we can't import
# exceptions from ZODB.POSException at top level (we're imported by
# our __init__.py, which is imported by ZODB's __init__, so the ZODB
# package isn't well-formed when we're first imported).
# from ZODB.POSException import TransactionError, TransactionFailedError

But yes, storm is outside of the nasty cycle - so it should be safe to just import ZODB.POSException at the module level. At the time I was just scared that there might be some zope magic going on (like deferredImport) and didn't pursue it further.

[James Henstridge (jamesh)]

I've attached a branch that implements the simple fix for this. It should work with both older and newer Zope's.

Perhaps the exception should be moved from the ZODB module to transaction at some point, but that is a decision for the Zope developers. And if/when they do make such a change, they'll likely continue to import it into ZODB.POSException for compatibility.

[James Henstridge (jamesh)]

Fix committed as r185