[ZODB-Dev] semantics of _v_ attributes?

Jim Fulton jim at zope.com
Wed Oct 6 10:19:32 EDT 2010


On Wed, Oct 6, 2010 at 4:52 AM, Chris Withers <chris at simplistix.co.uk> wrote:
> Hi All,
>
> I'm trying to fix this bug:
> https://bugs.launchpad.net/zope2/+bug/649605
>
> ...and I'm struggling to find documentation on the semantics of _v_
> attributes.

_v_ attributes should be dropped whenever an object's state is
cleared. This normally happens in response to _p_invalidate or
_p_deactivate, although objects sometimes override _p_deactivate as a
noop to try to avoid ghostification.

> In particular, surely this code:
>
>             base._p_activate()       # make sure we're not a ghost
>             base.__setstate__(state) # change the state
>             base._p_changed = True   # marke object as dirty
>
> ...should be enough to indicate that all _v_ attributes should be dropped?

No.

So, you want to update an object using old state.

I would use:

  base._p_invalidate() # remove state, including volatiles, no matter what
  base._p_activate()       # make sure we're not a ghost
  base.__setstate__(state) # change the state
  base._p_changed = True   # marke object as dirty

This isn't foolproof, depending on how an object uses _v_.  For
example if __setstate__ sets _v_s if they aren't already set, then the
above code would likely fail, as the _v_s would reflect the old state,
not the new.

If this use case is important, it would be better for ZODB tp provide
an API to handle this directly, so you didn't have to hack together
existing APIs.

I assume this code will ultimately be followed by a commit.

> If it isn't, what is the correct way to indicate to Persistent/ZODB that
> all _v_ attribute should be dropped not only for the current object

This would be more or less guarenteed by invalidating the object.

> but
> for all occurrences of that object across all connections to the current
> ZODB?

Well, for your use case, you're going to be committing a change to the
object.  That will cause instances of the object in all other
connections to be invalidated, dropping their volatile attributes.

Jim

--
Jim Fulton


More information about the ZODB-Dev mailing list