Is that really necessary for a filter? It seems that a filter implies
efficiency over a "scoring", and that filters should be able to be
evaluated in a chained (or priority queue) fashion fairly efficiently
without any need for 'rewrites".
With the new incremental updates of a filter (based upon a query) it
seems that the newly proposed filtering could be far less efficient.
I think a filter change that just removes the BitSet dependency is
all that is needed, and anything else is overkill, but I admit I am
probably missing something here.
If these changes will eventually allow for efficient filtering based
upon non-indexed stored fields I am all for it.
On Jul 8, 2006, at 2:24 AM, Paul Elschot wrote:
On Saturday 08 July 2006 05:44, robert engels wrote:
Agreed. The interface I proposed supports both sequential and random
access to the filter - hiding the implementation.
For query searching, random access to a Filter is only needed
in the forward direction, e.g. by nextInclude(docNr) or skipTo(docNr).
As for why it's so involved:
Making a "rewritten" Filter work more like a Scorer has the advantage
that combinations of filters can (also) be evaluated using the same
mechanisms as currently existing for Scorers. For this, some additions
to the existing code will be needed, like adding an
add(Filter, BooleanClause.Occur) to BooleanQuery, and a similar
addition of a Matcher (proposed superclass of Scorer to "rewrite" a
Filter to) to some of the underlying scorers.
Such occurrences of filters are only "must" and "must not", "should"
doesn't make sense because there is no score value.
Also, it makes sense to have an explain() method for a "rewritten"
Filter, because it can be for searching a query.
Regards,
Paul Elschot
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
