Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Z
ZODB
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Nicolas Wavrant
ZODB
Commits
fefa5024
Commit
fefa5024
authored
May 06, 2005
by
Tim Peters
Browse files
Options
Browse Files
Download
Plain Diff
Rebuild tag with fix for year-old bug in ZApplication.py,
noted by eyeball on zodb-dev by Stefan Holek.
parents
e08cfd0f
35c02219
Changes
3
Hide whitespace changes
Inline
Side-by-side
Showing
3 changed files
with
13 additions
and
7 deletions
+13
-7
NEWS.txt
NEWS.txt
+6
-0
src/ZODB/ZApplication.py
src/ZODB/ZApplication.py
+1
-1
src/ZODB/tests/synchronizers.txt
src/ZODB/tests/synchronizers.txt
+6
-6
No files found.
NEWS.txt
View file @
fefa5024
...
...
@@ -14,6 +14,12 @@ transaction
transaction object. As a result, the ``afterCompletion()`` methods of
registered synchronizers weren't called when the first transaction ended.
ZApplication
------------
- The ``__call__`` method didn't work if a non-None ``connection`` string
argument was passed. Thanks to Stefan Holek for noticing.
What's new in ZODB3 3.4a6?
==========================
...
...
src/ZODB/ZApplication.py
View file @
fefa5024
...
...
@@ -74,7 +74,7 @@ class ZApplicationWrapper:
if
connection
is
None
:
connection
=
db
.
open
()
elif
isinstance
(
type
,
basestring
):
elif
isinstance
(
connection
,
basestring
):
connection
=
db
.
open
(
connection
)
return
connection
.
root
()[
aname
]
...
...
src/ZODB/tests/synchronizers.txt
View file @
fefa5024
...
...
@@ -61,10 +61,10 @@ a weird traceback then ;-)
One more, very obscure. It was the case that if the first action a new
threaded transaction manager saw was a begin() call, then synchronizers
registered after that in the same transaction weren't communicated to
the Transaction object, and so the s
torage's afterCompletion() hook wasn't
called when the transaction commited. None of the test suites (ZODB's,
Zope 2.8's, or Zope3's) caught that, but apparently Zope3 takes this path
at some point when serving pages.
the Transaction object, and so the s
ynchronizers' afterCompletion() hooks
weren't called when the transaction commited. None of the test suites
(ZODB's, Zope 2.8's, or Zope3's) caught that, but apparently Zope3 takes this
path
at some point when serving pages.
>>> tm = transaction.ThreadTransactionManager()
>>> st.sync_called = False
...
...
@@ -75,8 +75,8 @@ at some point when serving pages.
>>> st.sync_called
False
Now ensure that
st.afterCompletion() gets called by commit despite that the
Connection registered after the transaction began:
Now ensure that
cn.afterCompletion() -> st.sync() gets called by commit
despite that the
Connection registered after the transaction began:
>>> tm.commit()
>>> st.sync_called
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment