lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: javadoc update help
Date Wed, 26 Aug 2009 14:26:36 GMT
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<markrmiller@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: uwe@thetaphi.de
>>>
>>>
>>>       
>>>> -----Original Message-----
>>>> From: Michael McCandless [mailto:lucene@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<markrmiller@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-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
>>>>
>>>>         
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>>
>>>       
>> --
>> - Mark
>>
>> http://www.lucidimagination.com
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>   


-- 
- Mark

http://www.lucidimagination.com




---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message