Tim Peters wrote at 2005-7-15 16:06 -0400:
...
Anyway, for reasons explained before, making a savepoint would still need to
copy the index, so I don't see that this would save anything worth saving.
It might allow skipping an index copy when a _rollback_ is done (at the cost
of clumsier coding
Tim Peters wrote at 2005-7-14 19:20 -0400:
...
[Dieter]
If we do, we can (usually) create a one with the state after the
restore.
[Tim]
Sorry, I couldn't follow that sentence.
After I have restored to a savepoint s, then the current state is
the one saved in s, thus the sequence:
[Dieter]
If we do, we can (usually) create a one with the state after the
restore.
[Tim]
Sorry, I couldn't follow that sentence.
[Dieter]
After I have restored to a savepoint s, then the current state is the
one saved in s, thus the sequence:
s.restore() # and eliminate from stack
Jeremy Hylton wrote at 2005-7-11 18:37 -0700:
IIRC, the old implementation of savepoints kept a copy of the index at
the time the savepoint was taken so that you could rollback to it
multiple times. I don't think there's any way to avoid such a copy.
Maybe, we keep the original implementation (a
[Jeremy Hylton]
IIRC, the old implementation of savepoints kept a copy of the index at
the time the savepoint was taken so that you could rollback to it
multiple times. I don't think there's any way to avoid such a copy.
[Dieter Maurer]
Maybe, we keep the original implementation (a savepoint
On 7/12/05, Tim Peters [EMAIL PROTECTED] wrote:
[Jeremy Hylton]
IIRC, the old implementation of savepoints kept a copy of the index at
the time the savepoint was taken so that you could rollback to it
multiple times. I don't think there's any way to avoid such a copy.
Right, and the
[Jeremy Hylton]
I understand. The further invariant is that the index captured when a
savepoint created is immutable.
Or at least acts like it. Copying is an easy-to-code and effective way to
ensure that, and I don't know of a better feasible way. Capturing a lot of
savepoints (or doing a
Christian Heimes wrote:
Today I stumbled over an unexpected behavior of savepoints. As far as
I'm able to understand savepoints they mark a well defined state in the
middle of a transaction. A savepoint is invalid if its transaction is
committed or another savepoint is created. Well nesting
Tim Peters wrote:
[Christian Heimes]
...
Something else strikes me. Why am I unable to roll back to the same
savepoint multiple times?
Because that's how it works wink. Maybe Jim can explain why quickly --
offhand I'm not sure. I don't think it could be guessed from the interface
docs:
[Christian Heimes]
...
From my point of view I can't see a reason why the ZODB forbids a
second rolback to the savepoint.
[Jim Fulton]
I agree. This should be changed.
Sounds good to me -- it looks easy, so I'll do it wink.
___
For more
[Christian Heimes]
From my point of view I can't see a reason why the ZODB forbids a
second rolback to the savepoint.
[Jim Fulton]
I agree. This should be changed.
[Tim Peters]
Sounds good to me -- it looks easy, so I'll do it wink.
Something subtler than I've been able to figure out yet
[Tim Peters]
Something subtler than I've been able to figure out yet is going wrong,
so I made a tim-savepoint branch. All the tests pass, but ...
Br. The pickle cache invalidate method (which is coded in C, so isn't
visible from pdb) clears the dictionary passed to it, and when using a
[Tim Peters]
...
The good news is that, while it was hard to find, it's a one-line repair.
Alas, that wasn't the end of it either. I think I'm at the end now, and all
the tests are passing again (including new tests to provoke new problems I
found).
A savepoint (of the data manager Connection
IIRC, the old implementation of savepoints kept a copy of the index at
the time the savepoint was taken so that you could rollback to it
multiple times. I don't think there's any way to avoid such a copy.
Jeremy
On 7/11/05, Tim Peters [EMAIL PROTECTED] wrote:
[Tim Peters]
...
The good news
14 matches
Mail list logo
