[PEAK] Recursive __setstate__ call

Radek Kanovsky rk at dat.cz
Fri Apr 16 08:58:32 EDT 2004


On Thu, Mar 25, 2004 at 11:52:02AM -0500, Phillip J. Eby wrote:

> So, it's almost certainly something wrong with the state management logic 
> in _persistence.c.  It might be possible to workaround by having 
> 'setstate()' force ob._p_changed to a particular state before calling 
> __setstate__, but I'm not sure.

Investigating persistence code I am almost sure that it is not
possible to revive ghost object without setstate invocation as
undesirable side effect. Any operation on ghost causes immediate
_PyPersist_Load() -> setstate() calling.

There are situations when this causes very inefficient behaviour.
Imagine SQL table representing tree. I want preload all children
of some node via typical SQL command ``SELECT * FROM tree WHERE parent=4''.
It works perfectly if DM cache is empty. But preloading objects that
are in cache in ghost state immediately triggers DM's _load method.
Then SQL log looks like this:

    SELECT * FROM tree WHERE parent=4
    SELECT * FROM tree WHERE id=5
    SELECT * FROM tree WHERE id=7
    SELECT * FROM tree WHERE id=8
    ...

Although we have all data from first SQL command, persistence machinery
doesn't believe us and wants to load every ghost object separately.
Deleting ghost objects from cache isn't desirable because these objects
can be referenced from other places.

I am missing some method like `ReviveGhostStateFromTrustedSource' in
persistence module. Has anybody simillar experiences? Or even solution?

Regards,

Radek Kanovsky



More information about the PEAK mailing list