Agreed. I'll open an issue...
Mike
On Wed, Aug 26, 2009 at 10:26 AM, Mark Miller<markrmil...@gmail.com> wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
