[Zope-dev] _p_deactivate() and _v_ variables?

[Casey Duncan]

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