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