[ZODB-Dev] ZODB _v_ attributes are tricky

[Paul Winkler]

On Fri, Apr 02, 2004 at 11:48:42AM -0500, Shane Hathaway wrote:
> Tim Peters wrote:
> >[Toby Dickenson]
> >
> >>The garbage collector can also be triggered explicitly by application
> >>code, and future improvements to the garbage collector might unload
> >>objects at other times too. In short, you should assume that _v_
> >>variables might disappear at any time.
> 
> ... or never, which equally confuses people.
> 
> >Part of the problem I perceive (and correct me if I'm wrong) is that the
> >docs are so lacking now that very few people are able to distinguish
> >accidental behavior from "officially supported" behavior.  I know for a 
> >fact
> >that Jeremy & I run into that repeatedly when trying to fix, or improve, or
> >even just clean up, internals.  We have large, interrelated, APIs, and
> >endcase behavior is often plain mysterious.
> 
> IMHO, _v_ attributes ought to be internal to ZODB.  Instead, ZODB ought 
> to provide two kinds of documented descriptors: Volatile and 
> TransactionalVolatile.  Volatile attributes revert to the default state 
> at any time;

or never, as you mention above?

> TransactionalVolatile attributes reliably revert to the 
> default state upon commit or rollback (including savepoint commit or 
> rollback).

this would be guaranteed? no maybes?

I'm attracted to this idea, Shane, on the surface it sounds easier
to work with. I haven't made heavy use of _v_ attributes precisely
because I have no good understanding of when they go away.

What might usage of your descriptors look like?
Similar to properties?  e.g.:


class Foo(Persistent):

    def _expensiveMethod(self):
        ...
        return data 

    _auto_caching_attribute = TransactionalVolatile(_expensiveMethod)

That looks pretty nice to me, but how would I trigger invalidation?

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's APOCRYPHAL MONITOR DOCTOR!
(random hero from isometric.spaceninja.com)