[ZODB-Dev] Lazy Instantiation

[frits.swinkels]

Thank you for the fast answer, particularly on a Saturday:)

I hope that Jim's remark re the ghost being the real object does not 
invalidate Tres' remark on the instance dictionary not being populated yet.

I noted the subtle point that "a.child is None" is safe.

Perhaps too much to ask: can I observe the state of the object (without 
changing it)? For example indirectly by logging data base access and 
noting that attribute access does cause data base access for a ghost.

I think I have enough to work with.


On 11-01-22 09:23 AM, Jim Fulton wrote:
> On Sat, Jan 22, 2011 at 9:09 AM, Tres Seaver<tseaver at palladion.com>  wrote:
>
> Thanks Tres.  I'll add few tiny fine points.
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 01/22/2011 08:54 AM, frits.swinkels wrote:
>>> I am new to ZODB and to this list: greetings.
>>>
>>> I need to get some points clear about precisely when objects are fully
>>> instantiated in memory. It may be a simple matter of pointing me at some
>>> documentation; I read pretty much anything I could find but there may a
>>> problem of your jargon being different from mine:)
>>>
>>> The main data structure of my application is a directed graph of nodes;
>>> each node has at least three slots which contain other nodes (e.g.
>>> parent, right child, left child; the parent always exists, the child
>>> slots may be None). I only want to instantiate that part of the graph
>>> that I am working on.
>>>
>>> Q1. I assume that when an object is instantiated, its "sub" objects will
>>> be in the form of some kind of proxy (perhaps that ghost I met in the
>>> ZODB How document?). Is this assumption correct?
> Note that the ghost is not a proxy.  It is the real object and is
> instantiated. It is in a special state that we call the "ghost" state.
>
>> Yes.  The ghost has not had its instance dictionary populated yet.
>> Attempting to access any instance attribute will "unghostify" the object.
>>> Q2. Given an object, designated by the variable a, in which of the
>>> following statements does the child become instantiated (activated?) ?
>>> child = a.leftchild
>>> name = child.name
>> The second (assuming that the nodes in your data structure derive from a
>> "persistent" base class, such as Persistent, or one of the BTrees),
>>
>>> Q3. Actually, before the child is instantiated, I somehow would like to
>>> query the object a, whether there is anything in the slot, i.e. whether
>>> the content of the slot is not None. Of course, this query should not
>>> trigger the instantiation.
> I assume you're talking about activation (instantiation isn't a good
> word here) of the child.  Simply getting the child won't activate it,
> but almost any operation on it will.
>
>    a.child is None
>
> won't cause the child to be activated, because it only use's the
> child's address, but:
>
>     a.child == None
>
> will because equality comparison will attempt to access
> methods on the child, which will cause it's activation.
>
> Jim
>