lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wolf Siberski <>
Subject Re: DO NOT REPLY [Bug 31841] - [PATCH] MultiSearcher problems with Similarity.docFreq()
Date Fri, 22 Apr 2005 08:08:11 GMT
Doug Cutting wrote:
> Wolf Siberski wrote:
>>> In each case applications should call a corresponding Searcher method.  
>> [...] 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, 
> Filter, HitCollector), just as they can call, 
> HitCollector). [...]

> 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). [...]
> Does this make sense?
Yes, it does. Keep Weight as internal class is very reasonable.
I misinterpreted the javadoc comments of
methods in so far as I had the impression that these methods should not
be used by applications anyway. But I see that this not the case.

Also your suggestion to delegate Weight creation to a Searcher method is
a good one. This allowed to pull up the (duplicate) implementation of
search(...) methods to Searcher. I'm not sure if it would be correct to
replace all calls to Query.createWeight() with Searcher.createWeight(),
so I left this as is.

When examining the code, I recognized that the same line of reasoning
applies to explain(), and made similar modifications. Also, one of
the tests in TestSort had to be modified to do a 'real' multi search.

An updated patch is attached to the Bugzilla issue.


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

View raw message