[ZODB-Dev] ZODB _v_ attributes are tricky

Tim Peters tim at zope.com
Fri Apr 2 11:28:08 EST 2004


[Shane Hathaway]
>> ZODB destroys volatile attributes only when
>> unloading objects.  ZODB unloads objects after another connection
>> changes them.  Also, the ZODB garbage collector unloads objects at
>> the end of transactions.

[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.

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.

So I think the docs need to be clear both about intended behavior, and about
implementation accidents (things that happen to be true today, but aren't
guaranteed to be true tomorrow (or yesterday <wink>)).  Any time we change
anything, it seems *somebody* out there is relying on the latter (but as
often as not don't realize they *are* depending on it -- "I don't know, but
it worked before, so it must be a ZODB bug if it doesn't work now").

OTOH, I'm not sure there are enough pixels to show the whole truth ...




More information about the ZODB-Dev mailing list