lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Justus Pendleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-998) BooleanQuery.setMaxClauseCount(int) is static
Date Tue, 10 Mar 2009 00:43:50 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message