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