You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Mark Miller <ma...@gmail.com> on 2009/08/26 02:14:29 UTC
javadoc update help
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
Re: javadoc update help
Posted by Michael McCandless <lu...@mikemccandless.com>.
Agreed. I'll open an issue...
Mike
On Wed, Aug 26, 2009 at 10:26 AM, Mark Miller<ma...@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<ma...@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<ma...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: javadoc update help
Posted by Mark Miller <ma...@gmail.com>.
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<ma...@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<ma...@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
Re: javadoc update help
Posted by Michael McCandless <lu...@mikemccandless.com>.
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<ma...@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<ma...@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
Re: javadoc update help
Posted by Mark Miller <ma...@gmail.com>.
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<ma...@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
RE: javadoc update help
Posted by Uwe Schindler <uw...@thetaphi.de>.
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<ma...@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
Re: javadoc update help
Posted by Michael McCandless <lu...@mikemccandless.com>.
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<ma...@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