Dan Korostelev wrote:
Hi, Chris and other developers.
I adapted repoze.catalog field index sorting code and tests for standard zope.index FieldIndex and looks like it works. :)
Though I like raising the KeyError when trying to sort docids that are not indexed, I had to remove it from interface declaration, and change it to skipping values as in ZCatalog/repoze.catalog. The problem is that it's not trivial to efficiently implement that checking in some cases. For example in FieldIndex sort method, in the use_lazy branch, set intersections are used and I can't see a way to check if some of docids are not indexed besides storing some additional variable which sucks. :)
I also adapted repoze.catalog's KeywordIndex fixes/optimizations to zope.index KeywordIndex and TopicIndex.
There is now also a "nadako-sorting" branch of zope.app.catalog. It adds sorting/limiting/reversing features to the "searchResults" method of catalog. It also introduces KeywordIndex for catalog, because I added support for IIndexSearch to zope.index KeywordIndex. :)
I request some review from developers and if there won't be any objections, I'll merge this code to trunks of zope.index and zope.app.catalog.
Looks good! A couple of things: - I'm tempted to ditch the case normalization feature of keyword indexes. This is actually the application's job; there's no guarantee that values that are passed by the app will be strings. I'm not sure that anyone has actually used keyword indexes, as their results could not until now be intersected with the results from any other index so there don't appear to be any backwards compatibility goals to service here (KeywordIndexes appeared to be abandonware until we paid attention to them). - Likewise, I don't think there are are any consumers of topicindexes, for the same reasons, so the "read on write" upgrade in FilteredSetBase should probably go. Users that have pickles around which are still IISets can do a migration. Thanks! - C