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
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 "vet
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 implementa
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 ha
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 reasons to mark a transaction as doomed, and I
would l
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 applicat
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:
>
>
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 w
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 th
I think the time would be better spent fixing ZODB to not allow a
transaction commit after a non-resolvable conflict error is raised.
Then bare except clauses would still be bad style, but not quite as
dangerous.
It'd be nice to add a test to the ZODB test suite that exposes the bug
so we can pro
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 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
commit if the marker still existed?
Yes, but Transaction obje
On Tue, 2003-02-11 at 13:19, Shane Hathaway wrote:
> Toby Dickenson wrote:
> > On Monday 10 February 2003 8:47 pm, Shane Hathaway wrote:
> >
> >
> >>>Great, so there's at least 133 things to examine to see if they
> >>>could catch a ConflictError. And I only wrote about 15 of those.
> >>>The res
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
On Tuesday 11 February 2003 11:04 pm, Leonardo Rochael Almeida wrote:
> On Tue, 2003-02-11 at 13:19, Shane Hathaway wrote:
> > I'm thinking the veto should be added by Connection.commit() and
> > Connection.setstate() whenever a conflict is about to propagate. What
> > do you think?
>
> Maybe I
17 matches
Mail list logo
