lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 26702] - [PATCH] arbitrary sorting
Date Fri, 06 Feb 2004 19:04:37 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26702>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26702

[PATCH] arbitrary sorting





------- Additional Comments From cutting@apache.org  2004-02-06 19:04 -------
Overall, it looks good to me, although I haven't tested it.

It would be better if this worked for arbitrary Searchable's, not just
IndexReaders.  The Searchable interface is designed to support distributed
search well, in particular, a query should only require a few calls through the
API without huge amounts of data.  In this case, the sort indexes should
probably only be created in the remote searchable, which means that the sort
type needs to be passed through with the query.  So perhaps the addition of a 

  TopDocs search(Query, Filter, int count, String sortField, int sortType)

method to Searchable would do the trick.  I think this would be easy to
implement for IndexSearcher, MultiSearcher and RemoteSearchable.  Does this make
sense?

Also, it's good to try to minimize the number of public classes and interfaces,
so that Lucene's public API is both easier to understand and support.  All of
the classes and interfaces you've added are public.  Do they really need to be?
 In particular, do you think folks will need to directly use the HitQueue and
Comparator classes or could these be made package private?

Perhaps my comments can be combined: if support for this were incorporated into
the Searchable interface directly, would any of these need to be public? 
There's also the issue of HitCollector-based access, which, by design, does not
work remotely, so an analagous sort-savvy HitCollector-based method would need
to be added to Searcher, the locus of local-only search methods.  So, with
these, could we hide the sort implementation classes entirely?

What do you think?

---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org


Mime
View raw message