Re: [ZODB-Dev] breaking out the transaction module from ZODB
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 ___
Re: [ZODB-Dev] breaking out the transaction module from ZODB
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
[ZODB-Dev] ZEO shutdown gives: Error in sys.excepthook
I have a ZEO application, occasionally on shutdown I see an intermittent error: Unhandled exception in thread started by Error in sys.excepthook: Original exception was: I've got a feeling I've seen this reported before on this mailing list, and it looks the same as the problem here http://osdir.com/ml/python.cherrypy/2005-12/msg4.html where it's judged to be harmless and caused by the way the python interpreter exits. I assume it's caused by the asyncore thread (I'm using zodb-3.7.2). Calling ZODB.Connection.Connection.close() followed by time.sleep(300) seems to stop this occurring in my case. Is there a cleaner/proper way? Thanks, Chris ___ 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
Re: [ZODB-Dev] breaking out the transaction module from ZODB
On Nov 8, 2007, at 1:59 PM, Chris McDonough wrote: 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? Seems logical, but I'm not looking that closely. :) ... 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"? Guido recently told me that people in the Python community at large assume that anything in the Zope namespace is assumed to be Zope specific, so I'd rather not put it there. There's a good deal of 3rd-party code that does "import transaction" Good point. I guess we should leave the package where it is. Note that then we have a tricky issue with avoiding having the package installed twice. I guess we should ignore this for now. :/ 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? Never mind. I guess we should leave it where it is. :) 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
Re: [ZODB-Dev] breaking out the transaction module from ZODB
On Nov 8, 2007, at 6:25 PM, Jim Fulton wrote: Why not subclass TransactionError? It didn't before. Should it? Seems logical, but I'm not looking that closely. :) OK. How about "zope.transaction"? Guido recently told me that people in the Python community at large assume that anything in the Zope namespace is assumed to be Zope specific, so I'd rather not put it there. Does it matter? People who are allergic to the name "zope" can probably lose. There's a good deal of 3rd-party code that does "import transaction" Good point. I guess we should leave the package where it is. Note that then we have a tricky issue with avoiding having the package installed twice. I guess we should ignore this for now. :/ It'd be no problem to provide the shims. - 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
Re: [ZODB-Dev] breaking out the transaction module from ZODB
On Nov 9, 2007 1:46 AM, Chris McDonough <[EMAIL PROTECTED]> wrote: > > On Nov 8, 2007, at 6:25 PM, Jim Fulton wrote: > > Guido recently told me that people in the Python community at large > > assume that anything in the Zope namespace is assumed to be Zope > > specific, so I'd rather not put it there. > > Does it matter? People who are allergic to the name "zope" can > probably lose. Well, it will be an uphill struggle to get people to use it, and that's bad, because the more people that use it, the more people will help code it... -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ 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
