lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: Numeric Range Filter - bug or documentation oversight
Date Sat, 06 Mar 2010 08:41:34 GMT
Hi Scott,

> But here's the issue that I solved but it seems like there is either a
> bug in the NumericRangeFilter or there is some additional documentation
> needed.  I created a NumericRangeFilter with a null for the min.  I
> would have thought that that meant the minInclusive could have been
> true
> or false and it wouldn't make a difference.  That wasn't my experience.
> It appears that it needs to be true for things to work the way I would
> expect.  It seems like that behavior should be documented or if it's a
> bug, it should be fixed (but maybe I'm missing a use case).

What problems are you experiencing? For min/max==null, the inclusive flags make no difference.
Can you provide a testcase? The code in NumericRangeQuery.NumericRangeTermEnum.<init>
(which is used for the filter, too) is keeping the lowest/biggest value for null values.

> Btw- I believe the example in the first part of the description of this
> class has the min and max values reversed.
> Filter f = NumericRangeFilter.newFloatRange("weight", 0.3f, 0.10f,
> true,
> true);

That is indeed wrong :-) I'll fix for 3.1.


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

View raw message