[ http://issues.apache.org/jira/browse/LUCENE-383?page=comments#action_12356018 ]
Yonik Seeley commented on LUCENE-383: ------------------------------------- The functionality is definitely needed, I'm just not sure of the API yet. I also have a ConstantScorePrefixQuery/PrefixFilter that just needs to be cleaned up a bit before it can be contributed. Doug, you had brought up the possibility of having a flag on Query indicating if it was constant scoring or not... it would be simpler than reproducing Constant versions of all the query types. The downside of that is the whole issue of query immutability... if you set the constant-scoring flag on the root query, it really needs to set it on all of it's sub queries (and hence changes them). You can easily get into trouble if a query is shared. To avoid changing queries, you would have to follow the same strategy as rewrite()... You would need to clone the query object, then set constantScoring, then call rewrite (which may clone it again). Not the best for performance... One solution is to communicate the fact that we want a constant scoring query in the rewrite method itself: rewrite(Query query, int flags) > ConstantScoreRangeQuery - fixes "too many clauses" exception > ------------------------------------------------------------ > > Key: LUCENE-383 > URL: http://issues.apache.org/jira/browse/LUCENE-383 > Project: Lucene - Java > Type: Bug > Components: Search > Versions: 1.4 > Environment: Operating System: other > Platform: Other > Reporter: Yonik Seeley > Assignee: Lucene Developers > Attachments: ConstantScoreQuery.java, ConstantScoreQuery.java, > ConstantScoreRangeQuery.java, ConstantScoreRangeQuery.java > > ConstantScoreQuery wraps a filter (representing a set of documents) and > returns > a constant score for each document in the set. > ConstantScoreRangeQuery implements a RangeQuery that works for any number of > terms in the range. It rewrites to a ConstantScoreQuery that wraps a > RangeFilter. > Still needed: > - unit tests (these classes have been tested and work fine in-house, but the > current tests rely on too much application specific code) > - code review of Weight() implementation (I'm unsure If I got all the score > normalization stuff right) > - explain() implementation > NOTE: requires Java 1.4 for BitSet.nextSetBit() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
