Why wouldn't we? Isn't it just as much of a break to have the QP start
spitting them off? Except now its confusing because you get something
different by default from the QP and by default from the direct object -
sometimes this could make sense, I don't think the QP has to be locked
into Query object defaults, but here it seems a bit odd to me.
Also, now if you parse the output of the Query object toString, you will
get different behavior - this isn't really a contract, but I think less
surprises is better.
- Mark
Michael McCandless wrote:
> 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
>
>
--
- 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
