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. Kevin _______________________________________________ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users