[Tim]
>> ...
>> But those details are all artifacts of exactly how your test case is
>> written. As a general rule, if you do a rollback _beyond_ the creation
>> of a new persistent object P, you shouldn't expect P to be in a useful
>> state anymore ...
[Dieter Maurer]
> As usual, an excellent ex
Tim Peters wrote at 2005-11-3 12:31 -0500:
> ...
>But those details are all artifacts of exactly how your test case is
>written. As a general rule, if you do a rollback _beyond_ the creation of a
>new persistent object P, you shouldn't expect P to be in a useful state
>anymore (and, as you've seen
On Thu, 3 Nov 2005 12:36:30 -0500
"Tim Peters" <[EMAIL PROTECTED]> wrote:
> [Tim Peters]
> > ...
> > When you later do
> >
> > sv = transaction.savepoint()
>
> Sorry! That should have said
>
> sv.rollback()
:-)
Thank you for your exaurient explanations, i have understand a lot of det
[Tim Peters]
> ...
> When you later do
>
> sv = transaction.savepoint()
Sorry! That should have said
sv.rollback()
> you're explicitly asking the transaction machinery to throw away _all_
> current state _that it knows about_. This now includes the state for
> commonWords[0], but not
[dvd]
> ...
> I'm using ZODB 3.5.1
OK.
[Tim]
>> ..
>> If I add
>>
>> transaction.commit()
>>
>> right after your
>>
>> data = root['data'] = OOBTree()
>>
>> then the POSKeyError goes away, and I get
>>
>> Traceback (most recent call last):
>> File "pos_dvd.py", line 34, in ?
>>
On Thu, 2005-11-03 at 09:44 -0500, Tim Peters wrote:
> You didn't say which version of ZODB you're using, but I doubt it matters:
> I was able to reproduce the POSKeyError in the current ZODB 3.6 branch.
I'm using ZODB 3.5.1
>
> I expect it's an artificial glitch due to never committing anything
[Tim]
> ...
> I'll open a Collector issue about the POSKeyError (extreme case or not,
> it shouldn't happen).
FYI, the Collector report is here:
http://www.zope.org/Collectors/Zope/1940
Thank you for the slim test case! That really helps.
___
For
[dvd]
> Hi all,
>
> I'm writing a framework on top of ZODB and I'm now investigate on a
> strange savepoint-related behavior (after a savepoint.rollback the
> attributes of a Persistent-derived class disappears)
>
> While investigate i write this code and found another strange behavior
> (maybe cor
