On Friday 26 September 2003 04:37 am, Toby Dickenson wrote: > On Friday 26 September 2003 09:32, Chris Withers wrote: > > Toby Dickenson wrote: > > > On Thursday 25 September 2003 11:51, Chris Withers wrote: > > >>Hmmm, does _p_deactivate() clear the contents of the object's _v_ > > >>variables? > > > > > > Yes > > > > Then given your earlier comment that _v_ variables are supposed to last at > > least teh length of the request, John's idea of using _p_deactivate() to > > reduce memory usage for large ZCatalog results sets could be seen as > > playing with fire, right? > > He had code that would only deactivate objects at the end of a loop if they > were not active at the start of the loop. Its not entirely safe, but I think > it mitigates the most serious risks here. > > ZCatalog (and others) have used this same technique for a while.
It should be entirely safe so long as the application does not store non-redundant data in _v_ variables. If the application does do this, then it needs to register the object as changed in the transaction and override __getstate__ so that the value of the _v_ variables are stored. I would argue that a better plan would be to only use _v_ vars for completely disposable data only. The application should expect that this values will be gone at any random time, not just at transaction boundaries. _p_deactivate is only effective if the object is in the "up-to-date" state. So if by some chance the object was changed after being loaded from the catalog results set, _p_deactivate() would do no harm. -Casey _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
