[ZODB-Dev] ZODB and ORBit-Python problems

Michel Pelletier michel@digicool.com
Mon, 21 May 2001 14:52:54 -0700 (PDT)


On Mon, 21 May 2001, Christian Robottom Reis wrote:

> On Sat, 19 May 2001, Jim Fulton wrote:
> 
> > Christian Robottom Reis wrote:
> > >
> > > On Fri, 18 May 2001, Jim Fulton wrote:
> > >
> > > This makes perfect sense. However, at times, an application has to do
> > > things both ways: use objects interactively with it's interface, loading
> > > and using objects as needed; and generate summaries from information
> > > contained in a series of objects.
> >
> > I don't think I understand you. I don't see what the above had to do
> > with loading *all* the objects from the database.
> 
> Sorry for being imprecise. I don't mean, necessarily, _all_ objects in the
> database; let's assume I have a collection of objects representing
> Sales (textbook example) that reference Employee objects. If I want to
> summarize how much employees sold, I either have to keep an autocalculated
> attribute, or generate a summary, in which case I _must_ load all objects
> from the database, and calculate the totals. So while sales are generates
> individually, summaries have to load all of them.

But not all of them at once.  You can throw away the employee object after
you are done sucking the statistical life-blood out of it.

This is why Jim mentioned _p_deactivate().  This will explicitly tell ZODB
to deactivate the object. (assuming, I think, that no references exist to
it an that its state has not changed).  You can also explicitly 'kick the
cache' by calling either _p_jar.cacheFullSweep() or
_p_jar.cacheMinimize().  I'm not sure what the exact different between the
two is, but I belie cacheFullSweep is the more agressive of the two.

> Following up on the last reply (since the matters are connected), I wonder
> when (if?) memory will be freed for them in time, and if there is
> something that can be done to let ZODB know we won't be needing it
> in-memory for the moment.

I'm not sure if there is any clear performance win with not loading an
object into memory after reading it, either way you do the IO, and that's
the slow part.

-Michel