On Monday 06 June 2005 14:31, Kevin Dangoor wrote:
> 1) the intid utility is used to maintain an object<->integer ID
> mapping for use as a document ID in catalog indexes. Given that the
> objects already have an integer ID, _p_oid, with a convenient API for
> moving back and forth between object and ID, why maintain two more
> btrees to hold this information?
Not all objects you want to index might be in the ZODB.
> 2) intid does not directly store an object pointer, but rather a
> reference object. Is the purpose here to allow you to work with parts
> of the result set without having to activate the original, potentially
> large, objects? Are the reference objects the place you would likely
> store metadata (I didn't see a facility in catalog itself for this)?
Yeah, I think this is the design goal. I think storing annotations on the
reference objects is probably the right choice.
> 3) I noticed that the .c extensions for the text index only have
> Python versions in 3.1. Was the performance difference not big enough
> to want to bring these across, or was it just a matter of amount of
> time available to get catalog running there?
The catalog was developed for Zope 3.1. There was no catalog in Zope 3.0. Or
is that not what you are asking for?
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope3-users mailing list