On Friday 27 January 2006 09:19, Morus Walter wrote:
> On Thu, 26 Jan 2006 11:33:50 -0800 (PST)
> Chris Hostetter <[EMAIL PROTECTED]> wrote:
>
> >
> > : It seems your interface requires that the SearchFilter know all of the
query
> > : results before hand. I am not sure this works well with the partial
result
> > : sets that Lucene supports.
> >
> > No, I'm not suggesting that. I'm saying that the SearchFilter would act
> > as an iterator over the doc ids that pass the filter -- regardless of the
> > what query might have been doen (in my work, i accutally use Filter's
> > without Queries quite a bit).
> >
> > My point was that with the interface you suggested, a searcher would have
> > to Score every doc, and then ask the SearchFilter if it should be included
> > in the results -- which could result in a lot of docs being scored
> > unneccessarily. I was suggesting an interface that would allow the
> > searcher to first ask the filter "what is the lowest doc id that you
> > allow?" score that doc, then say "what is the next doc id you allow?" and
> > score that one.
> >
> Hmm. I don't understand enough of lucenes internals but I always thought
> that the query selects the relevant documents.
> What you suggest sounds a bit like interchanging query and filter.
>
> What's preferable depends on the concrete situation I guess. For a
> filter accepting only very few documents and a query matching a large
> part of the index your way of using the filter first seems preferable.
> OTOH for a filter accepting most documents and a query matching just
> a few, I don't see why scoring each document that matches the filter
> should be of advantage.
> Especially if the filter has to do some calculation for each document in
> question.
>
> > Now that i write it out, i realize i'm bascially arguing for a Filter API
> > that looks a lot like the Scorer API -- just without the score method.
> >
> > Perhaps that's the best way to go: a generic "DocIterator" interface that
> > could be implimented by Scorer out of the box....
> >
> > public interface DocIterator {
> > public int doc();
> > public boolean next();
> > public boolean skipTo(int target);
> > }
> >
> But couldn't such a filter be implemented as a query returning some constant
> score then?
Yes, but a filter does not have a score, so it might be better to make this
a superclass/superinterface of Scorer, by leaving out the score() method.
The Scorer.explain() method might be worthwhile to keep, though.
Btw. the DocNrSkipper referred to earlier has this DocIterator functionality
in one method:
int nextDocNr(int)
returning -1 when there is no next document number.
Yonik mentioned that it would be good for performance to add this:
int nextDocNr()
implicitly using the last document number without the need to pass it.
The advantage of using -1 instead of boolean is that only one
return value needs to be used, saving a method call in many cases
during query search, but at the expensive of an extra test for the
return value being positive.
Regards,
Paul Elschot
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
