[
https://issues.apache.org/jira/browse/LUCENE-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680339#action_12680339
]
Justus Pendleton commented on LUCENE-998:
-----------------------------------------
I'd like to reopen discussion on this issue and, hopefully, see it resolved.
Our motivation for this is http://jira.atlassian.com/browse/JRA-13884
The single, global value for max clauses makes it difficult to use
BooleanQueries in different contexts effectively. In JIRA we might want "Find
Issues" to have a large max clause (especially because we need to add
permission clauses to the query) but for an AJAXy widget that helps you
autocomplete issues you want a much smaller max clauses: it would be better to
have the PrefixQuery fail in this context (at least, until more characters have
been typed in) than to use hundreds of megabytes of memory creating an O(number
of issues) BooleanQuery.
I don't follow Hoss Man's argument about why the method is static. I would
change this as follows:
- add a private non-static int queryMaxClauses to BooleanQuery. At construction
time it is set to the static maxClauses. setters and getters would be provided
to change it from the default. One problem with this approach that may impact
existing code is that changing the static maxClauses would no longer affect
already-created queries. I have a hard time imaging many people actually use
that behaviour but what do I know?
- change MultiTermQuery so there is some way to specify a new queryMaxClauses.
The subclasses Fuzzy and Range queries already have a profusion of constructor
arguments so I'd probably opt for another setter to avoid doubling the number
of those.
- find some way to actually make use of that queryMaxClauses. Right now the
abstract base class MultiTermQuery creates the BooleanQuery and doesn't provide
any easy way to inject the new queryMaxClauses should of overriding rewrite()
and duplicating 99% of the code. That probably means I'd put the
queryMaxClauses on MultiTermQuery directly.
I have patches to this effect locally but wanted to try to solicit some
feedback on the general approach before bothering to attach them.
Downsides that I can see to this approach:
- The aforementioned change regarding pre-existing queries not being affected
by changing the static value of maxClauseCount.
- Two or three extra function calls during query creation to fetch values. I
don't imagine this would affect performance in any substantial way for people
who don't use this functionality.
- A more complicated interface in MultiTermQuery for functionality that
(obviously) most Lucene users don't care about.
- There are places outside of MultiTermQuery that create BooleanQueries but
won't have a way for clients to modify the underlying BooleanQuery's
maxClauseCount.
> BooleanQuery.setMaxClauseCount(int) is static
> ---------------------------------------------
>
> Key: LUCENE-998
> URL: https://issues.apache.org/jira/browse/LUCENE-998
> Project: Lucene - Java
> Issue Type: Bug
> Components: Search
> Affects Versions: 2.1
> Reporter: Tim Lebedkov
>
> BooleanQuery.setMaxClauseCount(int) is static. It does not allow searching in
> multiple indices from different threads using different settings. This
> setting should be probably moved in to the IndexSearcher.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
