You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Paul Elschot <pa...@xs4all.nl> on 2006/05/23 09:24:34 UTC
Re: Explaining a filter; Scorer extending Matcher;
On Monday 22 May 2006 23:43, Chris Hostetter wrote:
>
> : In case Explanation is also to explain what a Filter does, it would need
to
> : have both a match flag and a score value.
>
> that's a good point, i hadn't considered hte possibility of "explaining"
> filters much ... but there's no reason why the "valueO 'f an explanation
> couldn't be an optional part of the explanation as well (ie: migrate from
> float to Float when adding the "Boolean match" so that future Explanation
> instances (of Filters) can say they match without claiming a particular
> score (or "faking it" with some magic float value)
>
> : At the moment I'm trying to implement filters by refactoring Scorer to
have an
> : abstract superclass Matcher that could also become a superclass for filter
> : implementations (instead of DocNrSkipper).
> :
> : This Matcher class has all methods of Scorer that are not using score
> : values: doc(), next(), skipTo(docNr).
>
> : Any thoughts on whether such a Matcher would be preferable to
> : a DocNrSkipper that only has this method:
> : int nextDocNr(int docNr)
>
> (I'm very ammused by this question, you'll see why in a second)
>
> I am 100% on board with the "Matcher" API you are describing ... but i
> think it might make more sense as an interface, perhaps called
> "DocIterator", that way even TermDocs could impliment it ...
>
> http://www.nabble.com/Filter-t1002705.html#a2605686
>
> :)
Well, I was about to add a reference to that thread at the
issue on compact sparse filters. The current patch there is
just the result of me trying to get something in that direction
to actually work, after mostly forgetting some of the "details"
of that thread.
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?
I don't know whether interfaces or abstract classes would be better for this.
Regards,
Paul Elschot
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Explaining a filter; Scorer extending Matcher;
Posted by Paul Elschot <pa...@xs4all.nl>.
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
scorer(reader).explain(doc)?
> 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
>
> ...in 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
this.
>
> 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
here: http://issues.apache.org/jira/browse/LUCENE-328
This makes Filter implement SkipFilter and it lets IndexSearcher
use the SkipFilter implementation when it is available.
The SkipFilter interface is here:
http://issues.apache.org/jira/browse/LUCENE-330
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.
Regards,
Paul Elschot
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Explaining a filter; Scorer extending Matcher;
Posted by Chris Hostetter <ho...@fucit.org>.
: 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 scorer(reader).explain(doc)?
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
...in 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 this.
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.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Explaining a filter; Scorer extending Matcher;
Posted by Doug Cutting <cu...@apache.org>.
Erik Hatcher wrote:
> Since we're moving forward with API refactoring discussions, on the
> topic of exceptions, perhaps its time to consider putting in our own
> exception class or hierarchy to decouple ourselves a bit from "IO".
> There are many in-memory non-disk-IO uses of these API's and having
> IOException being caught when it doesn't make sense (like iterating
> through tokens of a StringReader from an Analyzer, for instance).
Back-compatibility will be much simpler if new exceptions are subclasses
of IOException. But adding a Lucene-specific exception hierarchy would
be good hygiene. Does someone want to draft a proposal?
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Explaining a filter; Scorer extending Matcher;
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On May 23, 2006, at 4:26 AM, eks dev wrote:
>> "DocIterator", that way even TermDocs could impliment it ...
>
> I played with that idea and what I learned is that DocIterator
> should throw IOException as TermDocs throws it (It has been
> allready mentioned on compact sparse filters JIRA).
Since we're moving forward with API refactoring discussions, on the
topic of exceptions, perhaps its time to consider putting in our own
exception class or hierarchy to decouple ourselves a bit from "IO".
There are many in-memory non-disk-IO uses of these API's and having
IOException being caught when it doesn't make sense (like iterating
through tokens of a StringReader from an Analyzer, for instance).
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Explaining a filter; Scorer extending Matcher;
Posted by eks dev <ek...@yahoo.co.uk>.
>"DocIterator", that way even TermDocs could impliment it ...
I played with that idea and what I learned is that DocIterator should throw IOException as TermDocs throws it (It has been allready mentioned on compact sparse filters JIRA).
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org