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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
