On Nov 7, 2007, at 11:38 PM, Chris McDonough wrote:
I've begun work on breaking out the transaction module so it can be
used independently from ZODB.
Great!
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."""
+1
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?
- 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,)
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.
2,. If we really (really really) need to support catching POSError,
then perhaps we should mobe POSError
to the transaction package.
- 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.
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 think this is overly complicated. Let's just move or copy a few
things to transaction.
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.
Agreed,
Maybe just start transaction at "1.0" or something.
Yup.
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. :)
There is a more important issue that also suggests that moving the
package. A potential danger with distutils is that different
distributions can provide the same Python package, which is a recipe
for extreme confusion at best. Imagine someone installing
transaction 1.0 and ZODB 3.8.
I'd be *very* tempted to start a "z" namespace package (as I wish I'd
done a long time ago :) and put it there. Granted that claiming "z"
is also a bit presumptuous, but I think we'd have a reasonable clam
to it. :) Moving the package avoids accidentally installing 2
transaction modules at the same time.
And the name "zc.zodbutils" is just a placeholder, suggestions
from interested parties would be helpful.
Let's not even do this. See above,
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.
Thanks for working on this. See my comments above.
Jim
--
Jim Fulton
Zope Corporation
_______________________________________________
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