Right, it is confusing!
QueryParser has already cutover to auto constant score, by default.
But for direct instantiation of one of the MultiTermQueries, we still
default to scoring BooleanQuery, but have declared that in 3.0 this
will also switch to auto constant score. I'm tempted to simply switch
the default today, for 2.9, instead. Then your original proposed
javadoc is great.
Mike
On Wed, Aug 26, 2009 at 6:06 AM, Mark Miller<markrmil...@gmail.com> wrote:
> hmm...I guess this javadoc from MultiTermQuery confused me:
>
> * Note that {...@link QueryParser} produces
> * MultiTermQueries using {...@link
> * #CONSTANT_SCORE_AUTO_REWRITE_DEFAULT} by default.
>
>
> Uwe Schindler wrote:
>> Even the old RangeQuery does it. Only the new class TermRangeQuery uses
>> constant score (and the also deprecated ConstantScoreRangeQuery).
>>
>> -----
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: u...@thetaphi.de
>>
>>
>>> -----Original Message-----
>>> From: Michael McCandless [mailto:luc...@mikemccandless.com]
>>> Sent: Wednesday, August 26, 2009 11:33 AM
>>> To: java-dev@lucene.apache.org
>>> Subject: Re: javadoc update help
>>>
>>> Unfortunately, Prefix/Wildcard/FuzzyQuery, etc., still rewrite to scoring
>>> BooleanQuery by default, for now. In 3.0 this will change to constant
>>> score auto mode. At least, that's the plan now... however,
>>> QueryParser will produce queries in constant score auto mode, so we
>>> could consider changing the default for these queries in 2.9? If we
>>> don't want to change that default, how about something like this?:
>>>
>>> /** Set the maximum number of clauses permitted per
>>> * BooleanQuery. Default value is 1024. Note that queries that
>>> * derive from MultiTermQuery, such as such as WildcardQuery,
>>> * PrefixQuery and FuzzyQuery, may rewrite themselves to a
>>> * BooleanQuery before searching, and may therefore also hit this
>>> * limit. See {...@link MultiTermQuery} for details.
>>> */
>>>
>>> Mike
>>>
>>> On Tue, Aug 25, 2009 at 8:14 PM, Mark Miller<markrmil...@gmail.com> wrote:
>>>
>>>> Having a writers block here:
>>>>
>>>> /** Set the maximum number of clauses permitted per BooleanQuery.
>>>> * Default value is 1024.
>>>> * <p>TermQuery clauses are generated from for example prefix queries
>>>>
>>> and
>>>
>>>> * fuzzy queries. Each TermQuery needs some buffer space during search,
>>>> * so this parameter indirectly controls the maximum buffer
>>>> requirements for
>>>> * query search.
>>>> * <p>When this parameter becomes a bottleneck for a Query one can use
>>>>
>>> a
>>>
>>>> * Filter. For example instead of a {...@link TermRangeQuery} one can use
>>>>
>>> a
>>>
>>>> * {...@link TermRangeFilter}.
>>>> * <p>Normally the buffers are allocated by the JVM. When using for
>>>> example
>>>> * {...@link org.apache.lucene.store.MMapDirectory} the buffering is left
>>>>
>>> to
>>>
>>>> * the operating system.
>>>> */
>>>>
>>>> Okay, so prefix and fuzzy queries now will use a constantscore mode
>>>> (indirectly, a filter) when it makes sense.
>>>> So this comment is misleading. And the parameter doesn't control the max
>>>> buffer - it possibly provides a top cutoff. But now it doesn't even
>>>> necessarily do that, because if the Query uses constantscore mode
>>>> (multi-term queries auto pick by default), this setting doesn't even
>>>> influence anything.
>>>>
>>>> I started to rewrite below - but then it feels like I almost need to
>>>> start from scratch. I don't think we should claim this setting controls
>>>> the maximum buffer requirements for query search either - thats a bit
>>>> strong ;) And the buffer talk overall (including at the bottom) is a bit
>>>> confusing.
>>>>
>>>>
>>>> /** Set the maximum number of clauses permitted per BooleanQuery.
>>>> * Default value is 1024.
>>>> * <p>For example, TermQuery clauses can be generated from prefix
>>>> queries and
>>>> * fuzzy queries. Each TermQuery needs some buffer space during search,
>>>> * so this parameter indirectly controls the maximum buffer
>>>> requirements for
>>>> * query search.
>>>> * <p>When this parameter becomes a bottleneck for a Query one can use
>>>>
>>> a
>>>
>>>> * Filter. For example instead of a {...@link TermRangeQuery} one can use
>>>>
>>> a
>>>
>>>> * {...@link TermRangeFilter}.
>>>> * <p>Normally the buffers are allocated by the JVM. When using for
>>>> example
>>>> * {...@link org.apache.lucene.store.MMapDirectory} the buffering is left
>>>>
>>> to
>>>
>>>> * the operating system.
>>>> */
>>>>
>>>> I'm tempted to make it:
>>>>
>>>> /** Set the maximum number of clauses permitted per BooleanQuery.
>>>> * Default value is 1024.
>>>> */
>>>>
>>>> :)
>>>>
>>>> Anyone have any suggestions though?
>>>>
>>>> --
>>>> - Mark
>>>>
>>>> http://www.lucidimagination.com
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>>
>>
>
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
> ---------------------------------------------------------------------
> 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
