lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Williams <>
Subject Re: NumberTools
Date Tue, 22 Mar 2005 17:54:23 GMT
John Patterson writes (3/22/2005 12:56 AM):

>It would be great if this could be incorporated into Lucene as it will make
>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.
I 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  I used 
the following technique:
  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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message