lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <>
Subject Re: How to proceed with Bug 31841 - MultiSearcher problems with Similarity.docFreq() ?
Date Tue, 22 Feb 2005 18:44:38 GMT
Wolf Siberski wrote:
> The price is an extension (or modification) of the
> Searchable interface. I've added corresponding search(Weight...) methods
> to the existing search(Query...) methods and deprecated the latter.

I think this is the right solution.

> If Searchable is meant to be Lucene internal, then IMHO these 'duplicates'
> should be removed.

Searchable should be public, so that other RPC mechanisms may be used, 
rather than RMI.  Thus the architecture supports distributed search and 
RMI is just one potential platform.  Searchable is meant to be the 
abstract network protocol.  Queries, filters and sort criteria are 
designed to be compact so that they may be efficiently passed to a 
remote index, with only the top-scoring hits are returned, rather than 
every non-zero scoring hit.  HitCollector-based access to remote indexes 
is discouraged.  HitColletors are rather primarily meant to be used to 
implement queries, sorting and filtering.

The deprecated methods should be removed in Lucene 2.0.  We could 
probably remove them now without breaking anyone, but it's better to be 

> Regarding your other comments: I've been a bit too eager in refactoring,
> not giving enough thought to backward compatibility issues. Now I've
> reverted to existing API and behavior as far as (IMHO) possible,
> and that was pretty far. The only API change necessary is
> createWeight() _throws IOException_, because the idfs have to
> be computed in the Weight constructors.

I think that's okay.  Thanks for all your work!

> An improved patch is attached to the Bugzilla issue.

This patch now looks great to me.  +1

Does anyone object to comitting this patch?


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

View raw message