[
https://issues.apache.org/jira/browse/LUCENE-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054250#comment-16054250
]
Yonik Seeley commented on LUCENE-7880:
--------------------------------------
First, lets assume that having this global limit is a valuable way to catch
bugs (I disagree, but let's assume it for the sake of argument).
Now what if someone finds a place in their code where they legitimately need to
build a bigger scoring boolean query? What should they do? If they raise the
global static limit, they lose this valuable way to catch bugs. If one accepts
the first assumption, then it seems like one needs a way to override this limit
on a per query basis. If one does not accept the first assumption, then the
limit should simply be removed.
Even at a higher granularity, what if one collection wants one limit and a
different collection wants another limit (they could even be different
customers collocated in the same JVM). How should that be solved? See
SOLR-4586 for a more background / arguments.
If you are against the proposal in this issue, then what is your proposal to
address these issues Adrien?
> 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]
