lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <>
Subject [jira] Commented: (LUCENE-383) ConstantScoreRangeQuery - fixes "too many clauses" exception
Date Wed, 26 Oct 2005 21:49:55 GMT
    [ ] 

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
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:
>      Project: Lucene - Java
>         Type: Bug
>   Components: Search
>     Versions: 1.4
>  Environment: Operating System: other
> Platform: Other
>     Reporter: Yonik Seeley
>     Assignee: Lucene Developers
>  Attachments:,,,
> 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:
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message