[ 
https://issues.apache.org/jira/browse/LUCENE-9970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17350698#comment-17350698
 ] 

Chris M. Hostetter commented on LUCENE-9970:
--------------------------------------------


The simplest approach would probably be add an additional {{TooManyClauses}} 
constructor that allows the caller to set the exception message, and use this 
new constructor from the new IndexSearcher QueryVisitor code paths that throw 
{{TooManyClauses}}, with a new message clarifying that the number of nested 
clauses is the problem (since the initial query construction/rewriting would 
have already failed if a single sub-query was problematic)

that way any pre-9.x situations that caused {{TooManyClauses}} would continue 
to get the exact same message, only the "new" types of failure cases would get 
a slightly diff exception message

> 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
>            Priority: Major
>
> 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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to