-
Notifications
You must be signed in to change notification settings - Fork 24
/
CHANGES.txt
129 lines (97 loc) · 4.88 KB
/
CHANGES.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
Unreleased
----------
- Don't call `setUser` on transaction if there is no user logged in. This could
cause the username set on the transaction to be a strange string: " None".
0.7 (2012-12-30)
----------------
- Write unauthenticated userid and ``request.path_info`` as transaction
metadata via ``t.setUser`` and ``t.note`` respectively during a commit.
0.6 (2012-12-26)
----------------
- Disuse the confusing and bug-ridden generator-plus-context-manager "attempts"
mechanism from the transaction package for retrying retryable exceptions
(e.g. ZODB ConflictError). Use a simple while loop plus a counter and
imperative logic instead.
0.5 (2012-06-26)
----------------
Bug Fixes
~~~~~~~~~
- 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
<somestorage> is not supported.`` would be swallowed inappropriately.
0.4 (2012-03-28)
----------------
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.
Testing
~~~~~~~
- 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.
0.3 (2011-09-27)
----------------
Features
~~~~~~~~
- 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 ``tm.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,
response.headerlist)
Deprecations
~~~~~~~~~~~~
- 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.
0.2 (2011-07-18)
----------------
- 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``.
0.1 (2011-02-23)
----------------
- Initial release, based on repoze.tm2