On 6/6/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
> 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,
> _p_oid is not an integer.
Err... Yeah, that would be a good reason not to use _p_oid :)
I *thought* it was an int, but clearly it is an 8 byte string.
> > 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.
Aha! I wasn't thinking properly in Zope terms while I was playing with
this. I was forgetting about things like relational databases.
For my own needs at this point, everything in the catalog is going to
be in the ZODB, so a simple integer ID mapper without the extra
reference object should be fine.
As it stands now, the standalone catalog includes this simple integer
ID mapper and the catalog itself will instantiate one if you don't
pass one in. This makes it really easy to get going if you're just
creating a straightforward ZODB-based app.
> > Are the reference objects the place you would likely
> > store metadata (I didn't see a facility in catalog itself for this)?
I'm not going to worry about that until I see an actual performance
issue with my objects being activated...
Zope3-users mailing list