[Zope3-dev] zodb __parent__ and weakref

[Shaun Cutts]

Chris,

> -----Original Message-----
> From: Chris Withers [mailto:chris at simplistix.co.uk]
> Shaun Cutts wrote:
> > When a container gets pickled to be put into zodb, what happens to
the
> > subtree?
> 
> If the container has references to stuff that is contains, one of two
> things could happen:
> 
> 1. If the contents subclass persistent, then they will end up in their
> own pickle in the zodb and will be made persistent
> 
> 2. If they don't, they will still be persisted but will end up in the
> container's pickle in the zodb.
> 
> > Is it just left as a big "clump of stuff" for the garbage
> > collector to deal with?
> 
> As with all object, not until nothing references it ;-)

What I mean is this: assume that a subtree is *not* referenced anywhere
else. It seemed to me that, every time I did a refresh on a container
view from the browser, (__getstate__ and then) __setstate__ was called
on the container. I would think that means that all the old objects were
let go, and new copies were brought in.

This would seem to be relatively inefficient to garbage collect that
subtree. But it is 2x inefficient to have a tree with lots of cyclic
references embedded in it (via __parent__) to garbage collect.

However, the situation improves (in the vanilla case where the objects
themselves don't have lots of cross references) if __parent__ is a
weakref. Then the container, at least, can be immediately deallocated
without the garbage collector having to trace the cycles; then the
contained objects are also without references, and can be easily garbage
collected.

Further, it seems that the semantics of the situation dictate that the
references from contained.__parent__ to the container should never be
the ones keeping the container alive, anyway, as it is part of the tree.


But maybe my I'm misinterpreting the calls to __setstate__? It seems
unnecessary to call __setstate__ at all, as we already know the copies
in memory are fresh.

- Shaun