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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
