[ZODB-Dev] Re: Changes in _p_changed behaviour between Zope 2.7 and
2.9
Chris Withers
chris at simplistix.co.uk
Fri Apr 28 04:27:25 EDT 2006
Florent Guillaume wrote:
>> base._p_changed=0
>
> Marks the object not changed, to allow ghostifying.
>
>> base._p_deactivate()
>
> Ghostifies the object.
>
>> base.__setstate__(state)
>
> Updates the object's dict directly. This really shouldn't be called on a
> ghost object, I believe it's illegal but not checked. I'm not sure what
> happens anyway.
Right, that's what I figured too, and I'm guessing ZODB now does "the
right thing", which breaks history copy because history copy has this
bug ;-)
> base._p_activate() # make sure we're not a ghost
Ah cool, never new that existed...
> base.__setstate__(state) # change the state
> base._p_changed = True # marke object as dirty
>
> The "scrubbing" is not necessary, it's done by the __setstate__ C
> implementation of Persistent.
Okay, in that case we can loose everything funky before the __setstate__
call, right? How sure are you that __setstate__ will override
everything? I see that Evan specifically added the code to do the
scrubbing in revision 20478, sadly he didn't write tests or explain why
it was necessary :-S
> You don't need any transactions to at least test this sequence, only the
> Persistent base class and a dummy connection can be involved.
Hmmm, this smells like deep fu of which I am not capable ;-)
Are there any examples of this?
> To really test the history yes of course you'll need a full database. Many
> tests do that.
Oh, do you know of any examples I can look at?
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
More information about the ZODB-Dev
mailing list