I'm not sure if zope3-users is a more appropriate forum for this topic
than zodb-dev (probably is, which is why I'm here). I'm working on
(or, rather, have) a packaging of Zope 3.1's catalog for use with the
standalone ZODB. Packaging this up brought up a couple of questions:

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?

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)?

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?

All in all, making Zope 3.1's catalog work with standalone ZODB was a
far more enjoyable experience than working with Zope 2.8's.

Later this week, I'll toss a tar file up with this packaged catalog
for others to play around with.

Zope3-users mailing list

Reply via email to