On Tue, Apr 7, 2009 at 6:13 AM, Karl Wettin <karl.wet...@gmail.com> wrote: > > 7 apr 2009 kl. 10.23 skrev Michael McCandless: > >> Do you mean tracking the "atomic queries" that caused a given hit to >> match (where "atomic query" is a query that actually uses >> TermDocs/Positions to check matching, vs other queries like >> BooleanQuery that "glomm together" sub-query matches)? >> >> EG for a boolean query w/ N clauses, which of those N clauses matched? > > This is exactly what I mean. I do however think it makes sense to get > information about non atomic queries as it seems reasonble that the first > clause (boolean query '+(a b)') in '+(a b) -(+c +d)' is matching is more > interesting than only getting to know that one of the clauses of that > boolean query is matching.
Ahh OK I agree. So every query in the full tree should be able to state whether it matched the doc. >> A natural place to do this is Scorer API, ie extend it with a >> "getMatchingAtomicQueries" or some such. Probably, for efficiency, >> each Query should be pre-assigned an int position, and then the >> matching is represented as a bit array, reused across matches. Your >> collector could then ask the scorer for these bits if it wanted. >> There should be no performance cost for collectors that don't use this >> functionality. > > I'll look in to it. > > Thanks for the feedback. > > > karl > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
