New in version 0.5
June 27th, 2012
- When a non-retryable exception was raised as the result of a call to transaction.manager.commit, the exception was not reraised properly. Symptom: an unrecoverable exception such as Unsupported: Storing blobs in is not supported. would be swallowed inappropriately.
New in version 0.4 (March 29th, 2012)
- Bug Fixes:
- Work around failure to retry ConflictError properly at commit time by the transaction 1.2.0 package. See https://mail.zope.org/pipermail/zodb-dev/2012-March/014603.html for details.
- No longer tested under Python 2.5 by tox.ini (and therefore no longer tested under 2.5 by the Pylons Jenkins server). The package may still work under 2.5, but automated tests will no longer show breakage when it changes in ways that break 2.5 support.
- Squash test deprecation warnings under Python 3.2.
New in version 0.3 (September 28th, 2011)
- The transaction manager has been converted to a Pyramid 1.2 "tween" (instead of an event subscriber). It will be slotted directly "below" the exception view handler, meaning it will have a chance to handle exceptions before they are turned into responses. This means it's best to "raise HTTPFound(...)" instead of "return HTTPFound(...)" if you want an HTTP exception to abort the transaction.
- The transaction manager will now retry retryable exceptions (such as a ZODB conflict error) if pyramid.attempts is configured to be more than the default of 1. See the Retrying section of the documentation.
- Python 3.2 compatibility (requires Pyramid 1.3dev+).
- Backwards Incompatibilities:
- Incompatible with Pyramid < 1.2a1. Use pyramid_tm version 0.2 if you need compatibility with an older Pyramid installation.
- The default_commit_veto commit veto callback is no longer configured into the system by default. Use tm.commit_veto = pyramid_tm.default_commit_veto in the deployment settings to add it. This is for parity with repoze.tm2, which doesn't configure in a commit veto by default either.
- The default_commit_veto no longer checks for the presence of the X-Tm-Abort header when attempting to figure out whether the transaction should be aborted (although it still checks for the X-Tm header). Use version 0.2 or a custom commit veto function if your application depends on the X-Tm-Abort header.
- A commit veto is now called with two arguments: request and response. The request is the webob request that caused the transaction manager to become active. The response is the response returned by the Pyramid application. This call signature is incompatible with older versions. The call signature of a pyramid_tm 0.2 and older commit veto accepted three arguments: environ, status, and headers. If you're using a custom commit_veto function, you'll need to either convert your existing function to use the new calling convention or use a wrapper to make it compatible with the new calling convention. Here's a simple wrapper function (bwcompat_commit_veto_wrapper) that will allow you to use your existing custom commit veto function:
- def bwcompat_commit_veto_wrapper(request, response):
- return my_custom_commit_veto(request.environ, response.status,
- The pyramid_tm.commit_veto configuration setting is now canonically spelled as tm.commit_veto. The older spelling will continue to work, but may raise a deprecation error when used.
New in version 0.2.1 (September 5th, 2011)
- Fix MANIFEST.in on Windows (trailing slashes not permitted).
- Minor tox.ini changes.
New in version 0.2 (July 20th, 2011)
- A new header ``X-Tm`` is now honored by the ``default_commit_veto`` commit veto hook. If this header exists in the headerlist, its value must be a string. If its value is ``commit``, the transaction will be committed regardless of the status code or the value of ``X-Tm-Abort``. If the value of the ``X-Tm`` header is ``abort`` (or any other string value except ``commit``), the transaction will be aborted, regardless of the status code or the value of ``X-Tm-Abort``.