You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by Scott Smith <ss...@mainstreamdata.com> on 2010/03/06 08:53:45 UTC
Numeric Range Filter - bug or documentation oversight
I've been updating from 2.4.2 to 3.0.1. I had a number of issues (The
Version object in the analyzers was an "interesting" addition-I guess I
don't understand the use case for them. I understand what it says; I was
just surprised and it caused me some problems since I create analyzers
with reflection).
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).
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);
RE: Numeric Range Filter - bug or documentation oversight
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi Scott,
The only possibility you may get help is to provide us with some test code that builds an index and queries it to produce the error. The problem is that you gave us not enough information about your queries and index contents. Maybe you have some problems with precisionStep wrong (must be identical during indexing and searching)?
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Scott Smith [mailto:ssmith@mainstreamdata.com]
> Sent: Tuesday, March 09, 2010 7:22 PM
> To: java-user@lucene.apache.org
> Subject: RE: Numeric Range Filter - bug or documentation oversight
>
> Thanks for looking at this Uwe. I'll check my code again, but I tried
> changing it several times and it did seem to make a difference.
>
> Scott
>
> -----Original Message-----
> From: Uwe Schindler [mailto:uwe@thetaphi.de]
> Sent: Saturday, March 06, 2010 3:11 AM
> To: java-user@lucene.apache.org
> Subject: RE: Numeric Range Filter - bug or documentation oversight
>
> Hi Scott,
>
> I verified by an additional test in NRQ (Lucene trunk), that true/false
> together with null bound produces the same results, so there is no bug
> at all. This test is new, as it explicitly tests on an index containing
> infinity-float/min-max-integer values.
>
> The tests can be seen here:
> http://svn.apache.org/viewvc?view=revision&revision=919731
>
> If you still have problems, ask giving more details like a testcase.
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
> > -----Original Message-----
> > From: Uwe Schindler [mailto:uwe@thetaphi.de]
> > Sent: Saturday, March 06, 2010 9:42 AM
> > To: java-user@lucene.apache.org
> > Subject: RE: Numeric Range Filter - bug or documentation oversight
> >
> > 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.
> >
> > Uwe
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-user-help@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
RE: Numeric Range Filter - bug or documentation oversight
Posted by Scott Smith <ss...@mainstreamdata.com>.
Thanks for looking at this Uwe. I'll check my code again, but I tried changing it several times and it did seem to make a difference.
Scott
-----Original Message-----
From: Uwe Schindler [mailto:uwe@thetaphi.de]
Sent: Saturday, March 06, 2010 3:11 AM
To: java-user@lucene.apache.org
Subject: RE: Numeric Range Filter - bug or documentation oversight
Hi Scott,
I verified by an additional test in NRQ (Lucene trunk), that true/false together with null bound produces the same results, so there is no bug at all. This test is new, as it explicitly tests on an index containing infinity-float/min-max-integer values.
The tests can be seen here: http://svn.apache.org/viewvc?view=revision&revision=919731
If you still have problems, ask giving more details like a testcase.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Uwe Schindler [mailto:uwe@thetaphi.de]
> Sent: Saturday, March 06, 2010 9:42 AM
> To: java-user@lucene.apache.org
> Subject: RE: Numeric Range Filter - bug or documentation oversight
>
> 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.
>
> Uwe
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
RE: Numeric Range Filter - bug or documentation oversight
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi Scott,
I verified by an additional test in NRQ (Lucene trunk), that true/false together with null bound produces the same results, so there is no bug at all. This test is new, as it explicitly tests on an index containing infinity-float/min-max-integer values.
The tests can be seen here: http://svn.apache.org/viewvc?view=revision&revision=919731
If you still have problems, ask giving more details like a testcase.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Uwe Schindler [mailto:uwe@thetaphi.de]
> Sent: Saturday, March 06, 2010 9:42 AM
> To: java-user@lucene.apache.org
> Subject: RE: Numeric Range Filter - bug or documentation oversight
>
> 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.
>
> Uwe
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
RE: Numeric Range Filter - bug or documentation oversight
Posted by Uwe Schindler <uw...@thetaphi.de>.
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.
Uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org