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

[Casey Duncan]

On Wed, 10 Dec 2003 18:12:05 +0000
Toby Dickenson <tdickenson at geminidataloggers.com> wrote:

> On Wednesday 10 December 2003 16:17, Jeremy Hylton wrote:
> 
> > > There
> > > are cases where I set _v_ variables (and in fact it's most cases) where I
> > > could care less if the object is flushed on subtransactions. IOW I think
> > > using _p_dont_deactivate should be the exception and not the rule.
> 
> I suspect you believe this is safe because you are assuming that the cache 
> collector will never be activated at some points in your code, and you are 
> assuming that the cache collector will only be triggered by a subtransaction.

No, but I rarely ever use them at all. OTOH I'm sure I have written code in the past that has made this assumption, since its pretty easy to make.
 
> That assumption might be true in some limited cases today, but it is brittle. 
> Im sure something would break if code making this assumption was mixed with 
> some of my cache-hungry Zope Products.

In a sense this is a use case against your own aggressive cache flushing policy ;^)

> It will certainly not be true in future.... The extreme case is when we allow 
> the cache can trigger some deactivations itself, to prevent it ever growing 
> too large. I am assuming that what we design for volatile attributes today 
> will need to cope with this.

I still need to be convinced that more aggressive cache management policy is better but...
 
> For example, the following code would be unsafe, because self might get 
> deactivated (removing all _v_ attributes) between the hasattr check and using 
> _v_bar.
> 
>     def foo(self):
>         if not hasattr(self,'_v_bar'):
>             self._v_bar = self._make_bar()
>         ....use some other persistent objects
>         ....and self._v_bar at the same time.

Most of the time I insulate myself by adding an _v_ class attribute of None so that there is always some value there. Then the hasattr check is not necessary.

> I agree there are points in the lifetime of an object that uses _v_ attributes 
> where it can state that it no longer assuming that its _v_ attributes will 
> disappear arbitrarily. In Dieters original proposal, we need to support 
> self._p_keepv=0 . For safety, Im sure we need for any _v_ assignment to 
> automatically turn it on.

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

> > > Explicit is better than implicit.
> 
> Safe-by-default is better than explicit

Whatever works. I'll go on the record saying I would prefer to enable this behavior explicitly, Either way I am in favor of idea in general.

-Casey