[ZODB-Dev] [Problem] "_v_" variables too volatile

[Toby Dickenson]

On Wednesday 10 December 2003 19:01, Casey Duncan wrote:

> Unfortuately that adds a check to every setattr, which kinda sucks.

The persistent base class has to make this check anyway, since it is already 
handing assignments to _v_ attributes differently. Or maybe you meant a  
different check...


On Wednesday 10 December 2003 18:29, Jeremy Hylton wrote:

> > mixed with some of my cache-hungry Zope Products.
>
> Are there any examples I can look at?

My worst offenders are all proprietary (as is always the case ;-)

> I agree that _v_ variables don't seem very useful if they can disappear
> immediately after you assign to them, but in the current implementation
> they don't, right?

very rarely. In Zope terms, you need to call a method on some other component 
that touches alot of persistent objects then triggers the cache garbage 
collector. Things based on ZCatalog often get the blame.


On Wednesday 10 December 2003 18:12, Toby Dickenson wrote:

> I suspect it is true that much (but not all) of your code using _v_
> attributes could be rewritten to be safe under this type of cache
> management. For example, the code above could be converted to:
>
>     def foo(self):
>         try:
>             bar = self._v_bar
>         except AttributeError:
>             bar = self._v_bar = self._make_bar()
>         ....use 'bar' and some other persistent
>         ....objects at the same time
>
> Note that the self._v_bar attribute might have disappeared by the end of
> the function, but the 'bar' local will not. Unfortunately no code using _v_
> attributes today is prepared to defend against this.

Thinking further, I like the style of this option. Its a shame that it is not 
compatible with all the existing code. Does it make sense to have 
_v_attributes that are guaranteed to last until the transaction end, and 
_v_v_attributes (or whatever) that have no lifetime guarantees. Under Dieters 
proposal assigning to _v_attribute turns on _p_keepv, and assigning to 
_v_v_attribute does not.


-- 
Toby Dickenson