Jim Fulton wrote at 2006-10-6 12:10 -0400: > ... >I'm a little uneasy about baking this policy so deeply into >the infrastructure. I wonder if the use case can be handled >another way. > >A persistent object can override _p_deactivate. For example: > > def _p_deactivate(self): > pass > >prevents an object from being turned into a ghost unless it is >invalidated.
I think that this will not work -- unless more drastical changes are done to "persistent": When we invalidate an object, it must get deactivated. Now, currently invalidating a cache entry calls the object's "_p_invalidate" which calls "Per_set_changed(obj, NULL)" which uses "_p_deactivate" for the deactivation. With a definition like the above, the object will never again be deactivated -- not even when it is invalidated. >You could implement your sticky attribute at the application level: > > > def _p_deactivate(self): > if getattr(self, '_p_sticky', False): > return > Persistent._p_deactivate(self) > >You could provide any policy you want, without making the policy part >of ZODB. But, such an object would never again be deactivated (unless "_p_sticky" is reset). In my proposal, such objects may be invalidated at transaction boundaries. This may not be a big problem, as there are probably not too many objects that have "_p_sticky" defined permanently ("Shared.DC.ZRDB.Connection" and "Products.CMFCore.Skinnable.ObjectManager" would be examples). -- Dieter _______________________________________________ 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