lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <cutt...@apache.org>
Subject Re: DO NOT REPLY [Bug 31841] - [PATCH] MultiSearcher problems with Similarity.docFreq()
Date Thu, 21 Apr 2005 16:52:11 GMT
Wolf Siberski wrote:
>> In each case applications should call a corresponding Searcher method.  
> 
> Here I don't agree completely and have another suggestion to resolve that
> issue. The affected methods are low-level API methods anyway,
> and even before their javadoc referred application developers to other 
> already
> and still existing Searcher methods. If someone really needed to call 
> one of
> these methods before, IMHO he should now create a weight and call the
> corresponding new method.

I don't agree.  Applications shouldn't need to know about Weight.  Only 
folks who are adding new Query implementations should need to know about 
Weight.  Applications should be able to invoke Searcher.search(Query, 
Filter, HitCollector), just as they can call Searcher.search(Query, 
HitCollector).  The only difference is that these are convenience 
methods on Searcher, not core implementation methods on Searchable.  The 
core implementation methods require a Weight.  The convenience methods 
create an appropriate Weight.

It's not actually quite that simple.  The creation of the weight is 
different in different cases.  So we really need another core 
implementation method: Searcher.createWeight(Query).  By default this 
calls Query.createWeight(Searcher), but MultiSearcher will override 
this.  It's a Searcher method, not a Searchable method, since it should 
never be invoked on a RemoteSearchable.

Does this make sense?

Doug

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


Mime
View raw message