[ZODB-Dev] Recursion Error with ape and ZCatalog

[Shane Hathaway]

On Thu, 8 Apr 2004, Klaus Woelfel wrote:

> >
> > This doesn't happen when you index a smaller number of objects?
> >
> 
> Yes, it works up to about 2800 objects with 22 indexes. With 12 indexes in the 
> Catalog (and this time only one of them being a TextindexNG) it worked with 
> 5800 objects. 

I would normally suspect infinite recursion when the maximum stack depth
is exceeded, but the fact that it was exceeded only when the database grew 
makes me wonder if the need was legitimate.

> > Interesting.  The catalog is trying to store an acquisition wrapper,
> > which is a bug in the catalog.  However, I thought I fixed this one a
> > while back.  I wonder if I could make that error message display just a
> > little more info.  (BTW that OID of '9' is nice, isn't it?  Ape OIDs are
> > really simple now.)
> >
> 
> What info would be needed to find the bug?

I would need to find out exactly what kind of object was storing an
acquisition wrapper, then I would search the relevant source code for
something that stores acquisition wrappers.

> > You're doing nothing wrong.  ZCTextIndex apparently needs a minor fix
> > somewhere.  (Standard ZODB hides this error.)
> 
> at what would I have to look when I would try to fix it?

It's most likely somewhere in the ZCTextIndex code.  In particular, in 
Zope, you can't setattr(obj, name, obj.name) because "obj.name" generates 
an acquisition wrapper on the fly.  You have to setattr(obj, name, 
aq_base(obj.name)).

> >> Is the whole file loaded in memory when accessing one of the objects?
> >
> > Yes, by default Ape loads and stores database-like things as one big
> > file.  We should look at serializing BTrees in a more scaleable manner.
> >
> 
> is it the same in sql sorage?

Yes.

> Are there all objects in the BTree stored in one big cell?

Yes, currently.

> What happens if only one object changes - is the whole file / cell
> rewritten?

Yes, currently.

Shane