On Wed, 2003-02-12 at 04:23, Toby Dickenson wrote:
On Tuesday 11 February 2003 5:21 pm, Jeremy Hylton wrote:
On Tue, 2003-02-11 at 12:10, Shane Hathaway wrote:
I'd like to do the transaction states, because it would keep the code in
zodb3 and zodb4 similar.
There are application-level
On Thursday 20 February 2003 5:17 pm, Jeremy Hylton wrote:
There are application-level reasons to mark a transaction as doomed, and
I would like to keep *that* code looking similar ;-). The transaction
states approach would work in that context too, right?
Here's a late answer:
If an
On Thu, 2003-02-20 at 13:33, Toby Dickenson wrote:
On Thursday 20 February 2003 5:17 pm, Jeremy Hylton wrote:
There are application-level reasons to mark a transaction as doomed, and
I would like to keep *that* code looking similar ;-). The transaction
states approach would work in
Paul Winkler [EMAIL PROTECTED] wrote:
$ cd /usr/src/Zope-2.6.1-src/lib/python/Products/
$ find . -name *py -exec grep -H except: {} \; | wc -l
170
well, this is all stuff that comes with Zope, hopefully
they have been vetted... but then there's all these
'fraid not. These days they tend to
On Tue, 2003-02-11 at 04:13, [EMAIL PROTECTED] wrote:
Chris McDonough wrote:
Could this be done by initializing a dictionary at startup keyed on
thread-id that a ConflictError exception's __init__ could stick a marker
into, then checking that dictionary at commit time and disallowing the
Jeremy Hylton wrote:
On Tue, 2003-02-11 at 04:13, [EMAIL PROTECTED] wrote:
Chris McDonough wrote:
Could this be done by initializing a dictionary at startup keyed on
thread-id that a ConflictError exception's __init__ could stick a marker
into, then checking that dictionary at commit time and
On Tue, 2003-02-11 at 12:10, Shane Hathaway wrote:
I added a test to testZODB.py on a new branch
(shane-conflict-handling-branch) that exercises the conflict handling
bug. The test currently fails. It might be simpler to go with Toby's
implementation for now: add a veto object to the
Jeremy Hylton wrote:
On Tue, 2003-02-11 at 12:10, Shane Hathaway wrote:
I added a test to testZODB.py on a new branch
(shane-conflict-handling-branch) that exercises the conflict handling
bug. The test currently fails. It might be simpler to go with Toby's
implementation for now: add a
Shane Hathaway wrote:
Jeremy Hylton wrote:
On Tue, 2003-02-11 at 12:10, Shane Hathaway wrote:
I added a test to testZODB.py on a new branch
(shane-conflict-handling-branch) that exercises the conflict handling
bug. The test currently fails. It might be simpler to go with
Toby's
Romain Slootmaekers wrote:
Shane Hathaway wrote:
If we have veto(), it should probably expect a string argument that
explains the reason for the veto. Then if something tries to commit,
we can raise VetoedError(explanation). Otherwise, it seems like
failed transactions would be opaque and
Could this be done by initializing a dictionary at startup keyed on
thread-id that a ConflictError exception's __init__ could stick a marker
into, then checking that dictionary at commit time and disallowing the
commit if the marker still existed?
On Mon, 2003-02-10 at 15:47, Shane Hathaway
Chris McDonough wrote:
Could this be done by initializing a dictionary at startup keyed on
thread-id that a ConflictError exception's __init__ could stick a marker
into, then checking that dictionary at commit time and disallowing the
commit if the marker still existed?
Yes, but Transaction
On Mon, 2003-02-10 at 20:46, Chris McDonough wrote:
Could this be done by initializing a dictionary at startup keyed on
thread-id that a ConflictError exception's __init__ could stick a marker
into, then checking that dictionary at commit time and disallowing the
commit if the marker still
13 matches
Mail list logo
