[ZODB-Dev] How do you "wake up" sleepy persistent objects?

[Greg Ward]

On 11 October 2001, Jim Fulton said:
> First, you usually don't need to wake up ghosts. Why would
> anyone want to wake up a ghost? I can see doing it
> during debugging, but not otherwise.

I need to do this in Grouch, which walks an object graph and checks that
all objects are of "known" classes, have the right set of attributes,
and each attribute is of the right type.  The code in question is
generic -- lots of dir(), hasattr(), and getattr(), but not an
"object.foo" in sight.

If the object graph in question lives in a ZODB, then the first time we
hit each object, it's a ghost.  The first call to dir() always fails --
ie. it always returns [].  It looks like hasattr() and getattr() always
work right off the bat; it's only dir() that needs prodding.  As it
happens, my object-checking algorithm starts by calling dir() on the
object to be checked, to make sure it has the right set of attributes.
So before I do this "real" dir() call, I do "fake" dir() call to make
sure the object is awake:

    def _check_attrs (self, value, klass_def, context):

        # First, make sure there are no unexpected attributes.  (Doing this
        # first -- in the instance dictionary's hash order -- means the
        # *real* type-checking loop, below, is done according to the order
        # of attributes in the class definition, ie. in a predictable,
        # canonical order.  This is a good thing, if only because it makes
        # writing tests easier.)

        if context.mode == "zodb":
            # prod ZODB into loading the object before relying on
            # the value of dir()
            dir(value)

        all_ok = 1
        actual_attrs = dir(value)               # <- this fails without
        for actual_attr in actual_attrs:        #    the above "prod"

Sounds like this is pretty similar to Patrick's auto-completion feature,
although for a completely different purpose.

        Greg
-- 
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org