[ZODB-Dev] Changes in _p_changed behaviour between Zope 2.7 and 2.9

Chris Withers chris at simplistix.co.uk
Thu Apr 27 04:28:44 EDT 2006


Hi All,

I'm trying to fix this bug:
http://www.zope.org/Collectors/Zope/2062

And I've narrowed it down to the following lines in History.py:

         if serial != self._p_serial:
             self.manage_beforeHistoryCopy()
             state=self._p_jar.oldstate(self, serial)
             print '1:',state
             # Scrub the object before restoring the old state
             base = aq_base(self)
             base._p_changed=0
             base._p_deactivate()
             base.__setstate__(state)
             base._p_changed=1

             self.manage_afterHistoryCopy()

If I comment out the base._p_changed=0 and base._p_deactivate() then 
history copy starts working again.

My theory now is that the _p_deactivate() causes the persistence 
mechanisms to miss the changes made by base.__setstate__(state) and so 
when base._p_changed=1, it takes what it thinks is a ghost and stomps 
over it with the old state.

Does this sound plausible? If so, what's the correct fix here? Why was 
the scrubbing process necessary?

Also, just as importantly, how would someone suggest writing a test that 
excercises the above? The only thing I can thing of is creating a 
scratch filestorage somewhere and committing some transactions to it, 
but that seems a little heavyweight...

Oh well, any help greatly appreciated.

cheers,

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk



More information about the ZODB-Dev mailing list