[
https://issues.apache.org/jira/browse/LUCENE-9970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated LUCENE-9970:
---------------------------------------
Attachment: LUCENE-9970.patch
Assignee: Chris M. Hostetter
Status: Open (was: Open)
attaching patch that...
* Adds a string arg constructor to {{TooManyClauses}}
** also adds a {{getMaxClauseCount()}} method to access what the limit is/was
so it's available programatically even if the thrower doesn't include it in the
message
* Adds a {{TooManyNestedClauses}} subclass
** updates {{getNumClausesCheckVisitor()}} to throw this new
{{TooManyNestedClauses}} if it's check is exceeded
* update all existing {{TestMaxClauseLimit}} to explicitly check for
{{TooManyNestedClauses}} when expected
** and explicitly confirm that the base exception {{TooManyClauses}} was thrown
when the nested check shouldn't have been needed.
Patch also includes the following small related tweaks...
* rename {{TestBooleanQuery.testException}} to
{{TestMaxClauseLimit.testIllegalArgumentExceptionOnZero}}
* improves the comment in {{BooleanQuery}} to clarify that the (original) check
isn't just an early optimization - it's important in it's own right
* add a {{TestBooleanQuery.testTooManyClauses}} test confirming that adding
"too many clauses" to a BQ fails fast (w/o needing
{{IndexSearcher.rewrite(Query)}} to catch it with the recursive check)
> provide apps details about why TooManyClauses was thrown
> --------------------------------------------------------
>
> Key: LUCENE-9970
> URL: https://issues.apache.org/jira/browse/LUCENE-9970
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Major
> Attachments: LUCENE-9970.patch
>
>
> Historically, if {{TooManyClauses}} was thrown it meant exactly one thing:
> That a QueryX Builder (typically BooleanQuery, but there are a few others in
> sandbox) was not going to allow it's caller to add a clause because that
> QueryX object already had the maxClauseCount in _direct_ children.
> LUCENE-8811 added an additional "reason" why {{TooManyClauses}} may be thrown
> starting in 9.0: IndexSearcher may now throw this exception if the
> (rewritten) Query being executed has a _cumulative_ number of clauses –
> across the entire structure of _nested_ Query objects – that exceeds the
> maxClauseCount.
> ----
> I think it would be helpful to users if it was possible to tell from the
> {{TooManyClauses}} exception how the maxClauseCount was exceeded (because of
> the total number of direct children during rewrite, or cumulatively across
> the entire nested structure) w/o needing to inspect the stack frames to see
> if the thrower a rewrite method, or a QueryVisitor method.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
