After a little further digging, I've found that code of the same ilk exists in Zope 2's OFS.FindSupport, App.DavLockManager, Products.ZCatalog.ZCatalog and Products.ZCatalog.CatalogAwareness. Variants on the theme exist in CMFCore.CMFCatalogAware as well as CMFCore.WorkflowTool. As far as I can tell, wherever memory management through deactivation is employed in Zope 2 and CMF, it's done in a way that seems to have no useful effect, at least if my theory is right. - C On Jan 10, 2008, at 8:58 PM, Chris McDonough wrote:
Hi folks,
While messing with Zope2's webdav implementation, I ran across this bit of memory-management code:
dflag = hasattr(ob, '_p_changed') and (ob._p_changed == None) ... stuff ... if dflag: ob._p_deactivate()
I actually think this should be:
dflag = not getattr(ob, '_p_changed', None) ... stuff ... if dflag: ob._p_deactivate()
.. because when _p_changed on a persistent object (as I read it in the persistence interface file) is None, the object is a ghost. The object will never be a ghost here because non-_p_ attributes are looked up on it before we check for _p_changed, and even if it was a ghost, deactivating a ghost (to turn it into a ghost) is just not useful. I think the only time we don't want to deactivate it is if it has been changed (when _p_changed is True). Or at least that seems to be the intent.
Does this sound right? I have a feeling the answer will be crickets, but I figure what the heck.
- C
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists -http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )