Hmm ok, I can see those reasons.
> Unfortunately, ZCatalog does not expose this to the surface but you
> can write a trivial external method to do it. And I might entertain adding
> ZCatalog API to do so if I had a good use case.
Ah... I think this might be the best idea, I'll add that in to mine and, see
if anyone else wants it.
> Now that begs the question, If you already know the path to the object you
> are looking for, why are you using the Catalog in the first place? I
> doubt doing what you describe below is faster than just directly accessing
> the object. In fact I'd be willing to be its slower, especially since you
> are searching two indexes to get it.
Okay so lets assume there is only index I need to search, the path index.
Wouldn't it be faster to pull that out of the Catalog then do a traverse
over to the sub object, wake up a bunch of objects to do that and get the
object? It would be interesting to test that... perhaps Im just leaning on
the old crutch that its faster to get stuff from the catalog than wake many
objects up. Suppose I have 100 such objects. I would have thought one
catalog query on one index (even though its a big union) would be faster
than 100 traversals.
Anyway since I cant efficiently go and get an individual object from the
catalog, this is what Im doing now...
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -