[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