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.
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
