Kevin Dangoor wrote:
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,

_p_oid is not an integer.

> with a convenient API for
moving back and forth between object and ID, why maintain two more
btrees to hold this information?

To get integers and to get some indirection from the underlying storage,
which might not be 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?

No.  The main purpose of key references are to get valid keys.
Most objects are not valid persistent keys.

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?

Probably the later.  It probably wouldn't be hard.  The text index was
ported two years ago during a sprint.  I didn't even realize that anything
was left behind.

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.



Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-users mailing list

Reply via email to