[
https://issues.apache.org/jira/browse/LUCENE-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052964#comment-16052964
]
Erick Erickson commented on LUCENE-7880:
----------------------------------------
+1
My first reaction was that burdening the query writer with changing this
parameter would be pretty trappy. Then I realized that we could make it a
default or invariant either for all request handlers or individual ones.
Individual request handlers could even have different values, right?
If that's true, then I'd favor deprecating (and eventually removing support in
8.0) the naked <maxBooleanClauses> from solrconfig. Move it to an initParams or
just leave it out of the config completely and have it default in the code to
whatever we want if not specified on the query.
Really though any solution that got us around the fact that "last solrconfig
maxBooleanClauses loaded wins" trap works for me. +1 to this solution b/c it
gives us quite a bit of flexibility without making things trappy.
> Make boolean query clause limit configurable per-query
> ------------------------------------------------------
>
> Key: LUCENE-7880
> URL: https://issues.apache.org/jira/browse/LUCENE-7880
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Yonik Seeley
>
> As we know, the magic BooleanQuery.maxClauseCount has bitten many people over
> time.
> It's also a static, which really hurts multi-tenancy (i.e. we can't have
> different settings for different users, clients, or use-cases).
> If we want to keep this static as a default, then at least we should allow it
> to be overridden on a per-query basis when we know it is the desired behavior
> and not a bug.
> Perhaps the simplest way to achieve this would be a setter on
> BooleanQuery.Builder that configures the limit for that instance only?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
