John Patterson writes (3/22/2005 12:56 AM):
It would be great if this could be incorporated into Lucene as it will makeI just added "find the nearest x" to my app. I didn't need signed integers, but did need another feature. Finding the nearest x requires knowing what you want to find it near to, which is a query-time parameter. The current sorting mechanism does not have any provision for query-time parameters, although there is nothing intrinsic that makes this difficult or inefficient. I was able to achieve the result by specializing classes modulo one issue that required a patch (filed as issue http://issues.apache.org/bugzilla/show_bug.cgi?id=34028). I used the following technique:
numeric searches much more efficient. I will soon need to store simple
geographical data in my index to do a "find the nearest x" type of search.
1. Create a sort field with a custom SortComparatorSource that compares query-time and document geographical data by using a specialized ScoreDocComparator
2. Create the specialized ScoreDocComparator with a version of compare() that accepts the query-time location parameter, and a constructor that parses and maintains an efficient cache of the stored document geographical data (using the same technique as the built-in primitive types, so just as efficient)
3. Specialize FieldSortedHitQueue to take (in its constructor) the query-time location, to implement a version of lessThan that uses the query-time location to do compare's, and implements fillFields for the custom geographic data for support with MultiSearchers
4. Specialize IndexSearcher to use the specialized FieldSortedHitQueue for searches with sorts
This was all painless except for the filed issue. If there is going to be any generalization to built-in sorting representations, I'd like to suggest two things be included:
1. Fix issue 34028 (delete the one word "final")
2. Include a provision for query-time parameters
My opinion is that making the specialization a little more straightforward than the above would be more flexible than the proposed number parsers (which would have not helped in my case at all). With a simplified specialization architecture, it would be straightforward for any app to create parsers.
Chuck
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
