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
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
