lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Sanders" <>
Subject RE: Problem with Numeric range query.
Date Thu, 23 Sep 2010 21:10:42 GMT

I'm certain the timestamp field is being indexed.  It is created as follows: 

   Document doc = new Document(); 
   NumericField timeField = new NumericField("timestamp", 8); // Defaults to indexing = true.

   timeField.setLongValue( timeX); 
   doc.add( timeField); 


>>> "Uwe Schindler" <> 9/23/2010 3:02 PM >>>

> Thank you for your timely response.


> It's going to take me longer to create an isolated test case you can test
> with.  I will see what I can do.

That would be fine. Often with a simple test those errors disappear, because
they are problem in the logic somewhere else :) But you should in all cases
try this.

> In the meantime, I have some follow up information in response to your
> suggestions.
> 1) I don't think my problem is that the IndexWriter has not committed the
> document.  Here's why:
> In my test case, I first retrieve a document using a different lucene
query on a
> different field.  From that document I extract the value for timestamp
field and
> then perform the NumericRangeQuery on that value as described below.  I
> doing as a way to create a unit test that would verify that the
> NumericRangeQuery was working properly.  I think the fact that first query
> found the document is evidence that the IndexWriter had committed the
> document.  Hence, I would expect that if I follow that query with a
> NumericRangeQuery it should be able to find the same document.

Yes. But are you sure, that the timestamp is also indexed? If it's stored
only, it would not find that. Or maybe the other way round.

> 2) I also don't think my problem is values near Long.MIN_VALUE or
> Long.MAX_VALUE.  My values are all timestamps, which are positive integers
> that are not anywhere near those two extremes.  The values originally come
> from the java.util.Date.getTime() method.
> 3) I will try the upper+lower inclusive = true and using same value for
min and
> max, although I don't see how that will change anything.  I have actually
> debugged through the code for NumericRangeQuery, and if minInclusive ==
> false, then min is incremented, and if maxInclusive == false, then max is
> decremented.  So my query:
>    NumericRangeQuery.newLongRange("timestamp",8,timeX-1,timeX,false,true)
> is essentially equivalent to the query you suggest trying:
>    NumericRangeQuery.newLongRange("timestamp",8,timeX,timeX,true,true)
> right?

Yes, it is the same. The Lucene test
TestNumericRangeQuery64.testOneMatchQuery() verifies the upper=lower
inclusive=true thing.


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message