[
https://issues.apache.org/jira/browse/LUCENE-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16053018#comment-16053018
]
Mark Miller commented on LUCENE-7880:
-------------------------------------
I'm all for trappy limits that pop up out of the blue because devs know better
than me about my resources and use cases and where stuff should just start
failing for my own good with runtime exceptions.. I've been meaning to make
sure you can only have 5 segments before exceptions are thrown as well. A lot
of performance seems to drop off that and users might be get confused without
their app breaking at 5. Once I sneak that in, I intend to veto lock it till
2035 when hardware might be up to the task of tearing me from my death veto
grip, as which time 6 segments can be the new dev knows when to exception screw
you limit.
No wait. I take it back. That was the paranoid inducing vodka talking.
> 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]
