lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Elschot <>
Subject Re: Explaining a filter; Scorer extending Matcher;
Date Tue, 30 May 2006 18:49:06 GMT
On Tuesday 23 May 2006 20:05, Chris Hostetter wrote:
> : I'll repeat the DocIterator from that thread:
> :
> :      public interface DocIterator {
> :          public int doc();
> :          public boolean next();
> :          public boolean skipTo(int target);
> :      }
> :
> : to come to my question: should that interface should also have an
> : explain(int docNr) method?
> : When so, it does more than iterating, so it might even be called Matcher.
> : Or would both DocIterator and Matcher be useful?
> that's a damn fine question, and the most opinionated answer i can give,
> is "i don't know".
> Setting aside for the moment discussion about refactoring a common
> interface used for both scoring and filtering, Let me raise some seemingly
> unrelated questions:
>    1) Does it make sense from an API perspective for both Weight and Scorer
>       to have explain methods (ignore migration issues that might be
>       involved in making the change naow, imagine if we were starting from
>       scratch) ?
>    2) Should Weight.explain(IndexReader,doc) allways call 
>    3) Should Weight.explain be deprecated in favor of usage in #2
>    4) should Scorer.explain be removed, and Weights that want to delegate
>       to their Scorer can do so if-and-only-if the Scorer class they use
>       specificaly declares the method (as oppose to now where many Scorer
>       implimentations throw UnsupportedOperationException when they expect
>       their corrisponding Weight to take care of it
> my optinion, the answers to those questions should drive any
> question of wether a "Matcher" API which is intended to be
> implimented/superclass of Scorer should contain an explain method.  And
> assuming the idea of being able to "explain" Filter's appeal to people,
> then should the Filter API have an explain method ala Weight, or should
> the Matcher returned by Filter.getMatcher(IndexReader) have an explain
> method.
> I honestly don't know.
> : I don't know whether interfaces or abstract classes would be better for 
> At this point ... i think many interface/abstract-class decissiosn in
> Lucene have to be based more on the migration path of least change
> then by any sense of correct design principles.

As far as I can see the smallest change would be the SkipFilter1.patch
This makes Filter implement SkipFilter and it lets IndexSearcher
use the SkipFilter implementation when it is available.
The SkipFilter interface is here:

The next step would then be a global replacement of Filter by
SkipFilter in all API's, together with the addition of a test for
  filter instanceof Filter
in IndexSearcher for backwards compatibility in case no
DocNrSkipper is provided as SkipFilter.

To allow adding things in DocNrSkipper (for example a method
nextDocNr() without argument), DocNrSkipper could be implemented
as an abstract class instead of as an interface.

Explaining a filter might be done by FilteredQuery only.

Paul Elschot

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

View raw message