I think it would be quite clean if all XXXQuery classes that simply
enumerate certain terms and then match all docs containing those
terms, would subclass MultiTermQuery which itself would implement
set/getRewriteMethod?
I guess we'd also create a MultiTermFilter, which is basically the
same as TermsFilter from contrib/queries.
And then no more separate ConstantScoreXXXQuery classes... so we'd
deprecate ConstantScoreRangeQuery.
At least these [core] queries should fit this refactoring: RangeQuery,
PrefixQuery, WildcardQuery, FuzzyQuery.
I don't think I'll have time near-term to do this myself... but I do
think it's a good step forward, to bring constant-score rewriting to
all of these XXXQuery classes.
Mike
Uwe Schindler wrote:
>> Michael McCandless (JIRA) wrote:
>>> I do like the idea of adding "constant score capability" to the
>>> existing query classes, instead of adding new ConstantScoreXXXQuery
>>> classes.
>>>
>> I am torn on this one. Not against the idea, but I think it should be
>> consistent with ConstantScoreRangeQuery, and it seems a bit awkward
>> to
>> deprecate that at this point. Not a huge deal either way I guess
>> though.
>
> In my opinion, RangeQuery should also have this boolean flag for
> consistency. Deprecating ConstantScoreRangeQuery is not so nice, but
> needed.
> A workaround would be:
>
> ... RangeQuery ... {
> public Query rewrite(IndexReader r) {
> if (constantScore)
> return new ConstantScoreRangeQuery(...).rewrite(r);
> else...
> }
> }
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
|