Hoss, what about radical approach :) Instead of "Decouple Filter from BitSet"
change target to "add support for Matcher", meaning:
- do not change Filter and existing search() method in InedexSearcher at all,
leave it as it is, no new assumptions about anything
- Add IndexSearcher.search() method that uses Matcher and makes documented
assumption that Scorer used to score supplied Query supports skipTo.
how I see it, as long as we have this degree of freedom, "optional support for
skipTo() in Scorer", we will have to have implicit knowledge of this fact for
any code that interacts with Scorer, one way or another.
Making skipTo() required for scorers would be nice, big, simplifying change,
but this is *way out of my league* to argue something like that (I simply have
no idea what implications, effort... this could have).
this would work as this search method with Matcher gets "expert" status until
we find a way to relax this assumption. and actually do what we wanted in the
first place "decouple Filter from BitSet"
cheers, e.
----- Original Message ----
From: Chris Hostetter <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Saturday, 14 April, 2007 1:13:21 AM
Subject: Re: [jira] Commented: (LUCENE-584) Decouple Filter from BitSet;
relation with LUCENE-730
: > Hoss, would this work (is this what you said)?
: > public Matcher getMatcher(IndexReader reader) throws IOException {
: > if(bits() == null) throw new SomeException("Filter must implement at least
: one of...");
: > return new BitsMatcher(bits());
: > }
Assuming BitsMatcher does what i think it does then yes, that's what i had
in mind ... i was specificly saying to make a default Matcher
implementation out of the code in the patched version of IndexSearcher
that has the comment...
+ } else { // bits for filtering, skipTo() not used on scorer:
: This will not work correctly when the Scorer for the query that is searched
: with a filter does not implement skipTo(), for example BooleanScorer.
: See also the javadoc of class IndexSearcher in the patch.
I don'tget it, how would a Scorer not implement skipTo? ...oh...
final class BooleanScorer extends Scorer {
...
public boolean skipTo(int target) {
throw new UnsupportedOperationException();
}
...so lemme see if i understand this:
What's happening in the current trunk is that the only situations
in which code will attempt to call skipTo on a Scorer are:
a) From the score(HitCollector hc) method of the same Scorer class
(you should know if you suport it, you're in the class)
b) From the skipTo method of an enclosing Scorer
(If you "add" Scorer X to a a wrapper Scorer Y, and Y implements
skipTo, it can assume that X implements skipTo).
Am I correct so far?
In the latest version of the Matcher patch...
https://issues.apache.org/jira/secure/attachment/12352057/Matcher20070226.patch
...this changes, such that IndexSearcher will assume a Scorer supports
skipTo iff a Filter is used which implements getMatcher (I guess the
assumption being that if the code being used is new enough to support Matchers,
it's
new enough to support Scorer.skipTo). *BUT* if it's an "old" Filter using
a BitSet the code in IndexSearcher will continue with the same old
assumptions about the Scorer.
And the change eks describes (which is a much better way to describe what
i was suggesting) would break this safety net by always assuming skipTo
was safe to call.
So really the issue is that the patch assumpes one thing (Scorer supports
skipTo) based on the presence of something that should be thought of as
"newer" (Filter supports getMatcher) and relying on documentation to
enforce this.
Am I caught up now?
Off the top of my head, the best solution i can think of to this issue
would be to add the naive implementation of skipTo to Scorer, remove
the UnsupportedOperationException of skipTo from all Scorers in the core,
and rev Lucene to version 3.0 since this would probably be considered a
serious API change (method sigs don't change, but now we're requiring
people to implement a method that we have said in the past (by example)
can be Unsupported.
In general i'm not fond of assuming Scorer.skipTo when Filter.getMatcher
... the concepts are really orthoginal and even if it's a decent
assumption to make today, it doens't help us tomorow when we want to add a
getMatcher method to all of the core Filter classes to improve
performance.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
___________________________________________________________
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for
your free account today
http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
