On 28/09/2010 12:55, Tres Seaver wrote: > On 09/28/2010 03:36 AM, Chris Withers wrote: >> On 28/09/2010 00:12, Marius Gedminas wrote: >>> --- ./OFS/History.py.orig 2010-09-28 02:11:56.535745440 +0300 >>> +++ ./OFS/History.py 2010-09-28 02:12:00.043764683 +0300 >>> @@ -151,6 +151,9 @@ >>> base = aq_base(self) >>> base._p_activate() # make sure we're not a ghost >>> base.__setstate__(state) # change the state >>> + for attr in dir(base): >>> + if attr.startswith('_v_'): >>> + delattr(base, attr) >>> base._p_changed = True # marke object as dirty >>> self.manage_afterHistoryCopy() >> >> Thanks, I guess I'll monkey patch for now, here's the bug: >> >> https://bugs.launchpad.net/zope2/+bug/649605 >> >> However, I'm curious, so the above will fix the object in the current >> thread, but what about objects in other threads? >> >> (or do _v_ attributes get killed off at the start of each transaction?) > > Only when objects are ghostified (due to an invalidation from another > thread or process) or evicted from the cache. I'm not quite sure how > the case you are triggering occurs, but if that code saves the new-old > version of the template to the ZODB, then any instances in other > threads' connection caches should be invalidated.
Feel free to repeat the steps I originally posted and are in the bug description ;-) Looks like the History.py code isn't doing something it should, but I don't know when or what changed to make this so. I'll CC zodb-dev in case Jim knows of any changes in ZODB (I'm using 3.9.6) that might be relevant... cheers, Chris -- Simplistix - Content Management, Batch Processing & 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 https://mail.zope.org/mailman/listinfo/zodb-dev