lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Elschot <paul.elsc...@xs4all.nl>
Subject Re: Explaining a filter; Scorer extending Matcher; (was: BooleanWeight.normalize(float) doesn't normalize prohibited clauses?)
Date Sun, 21 May 2006 21:04:02 GMT
On Sunday 21 May 2006 21:06, eks dev wrote:
> 
> "Any thoughts on whether such a Matcher would be preferable to 
> a DocNrSkipper that only has this method:
>   int nextDocNr(int docNr)
> ?"
> 
> As far as I can comprehend, it makes a lot of sense to decouple Scoring from 
Matching (of course their intermixing as well).  This would practically mean 
that complete Query execution  mechanics could be reused instead of making 
"paralel world" of non scoring queries/ChainedFilters... 

Query execution is always done by a Scorer.

> 
> Please correct me if understanding is wrong:
> - It would enable one Clause in BooleanQuery to be "pure boolean" (aka 
constant scoring)

No, for the reason above. There already is a ConstantScoreQuery that
has a constructor that takes a Filter argument.

> - it would permit Filter-s to be combined without "external helpers" like 
ChainedFilter by using Matcher only, by purely using existing Query

Same situation. However, it might be possible to refactor the Matcher
logic out of the various scorers used by boolean query to be reused for
boolean operations on filter like things, but I wouldn't expect much to
be gained from that.

> 
> 
> DocNrSkipper and such Matcher are semantically the same,  it couldd work 
just the other way round  as well where  Matcher implements  DocNrSkipper. 
DocNrSkipper just skipps docs, Matcher can do u bit more so the other option 
could even be ok? Anyhow, sounds like style question    

A Matcher needs a little bit of dynamic state in the form of the current
document number, and DocNrSkipper does not have that, so they
are not completely equivalent. 

As for the style, I have no preference either way. Doing a filtered search
in IndexSearcher takes only a few lines more code than a non filtered search
in any case.

Regards,
Paul Elschot

---------------------------------------------------------------------
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