Old test case fails on NumericRangeQuery on NumericField

neek · **Joined:** Wed Sep 30, 2009 5:29 am **Posts:** 29

I have an old test case I'm dusting off. I've moved up to Search 420 with Lucene core 3.6.2 jars. The .class files and lucene index files are completely recreated each time the test case runs so I'm not using old files by mistake.

My test case fails because a query returns 0 results. Other test cases for non-Numeric fields work fine, it's just @NumericField queries that are failing.

It also fails in Luke, which I'll concentrate on here because it removes my test case code from the situation. I cannot query for "cc:7" in an index where I can see there certainly is a Document with a 'cc' field of value 7.

My test entity has a 'cc' field:

Code:

@Entity(name="bikes")
@Table(name="bike_items")
@Indexed
public class BikeEntity extends ItemEntity {
[cut]
   @Column(nullable=false)
   @Field(index=Index.YES, analyze=Analyze.NO, store=Store.YES)
   @NumericField
   @Analyzer(impl=org.apache.lucene.analysis.standard.StandardAnalyzer.class)
   private Integer cc;

My test case creates a Hibernate Search connection and creates 10 entities each with a different value for 'cc'. Running Luke 3.5.0 I can see 'cc' in the list of fields in the Overview, and going to Documents I can see that most documents have a 'cc' field like this:

Code:

Field  IdfpTSVopNLB#  Norm  Value
cc     Id--TS------#  ---   7

So the field is Indexed, Tokenized (which I think would have no effect on my problem?), Stored (irrelevant but handy to see in the index while debugging) and Numeric (so string padding with zeroes etc. isn't relevant).

In the Search pane of Luke, the Analyzer is set to StandardAnalyzer and a search of "cc:7" returns no results. This should return 1 result.

If I enable "Allow leading * in wildcard queries" and search for "cc:*" I do get a full list of documents, including the one with cc=7.

I've tried specifying the @Analyzer annotation as SimpleAnalyzer, with similar change in Luke to set the analyzer used during Search, but it didn't help. Also tried leaving the @Analyzer out entirely, still no help.

Does anything here seem amiss? I've been scratching my head for a while. I don't feel that writing a bunch of Java code to directly interrogate the index would help, if even Luke cannot return results.

Nick

neek · **Joined:** Wed Sep 30, 2009 5:29 am **Posts:** 29

I've run into this old thread http://lucene.472066.n3.nabble.com/Problems-with-RangeQueries-td2918069.html where it is said:

Quote:

Luke cannot search NumericFields correctly, as the official Lucene
QueryParser does not produce numeric ranbge queries, as it does not know
that the field is numeric. It uses a TermRangeQuery and that may hit random
documents.

Indeed when I type "cc:7" into the Luke search and hit "Explain structure" I see:

Code:

TermRangeQuery, inclLower=true, inclUpper=true
  lowerTerm=cc:0'
  upperTerm=cc:7'

I guess this should be a NumericRangeQuery and therefore fails. This is frustrating, Luke seems so capable other than this, and knows the field is a Numeric field according to the Flags printed for the 'cc' field on the Documents pane.

My test case that's failing is using NumericRangeQuery. I'll have to give up on Luke for anything involving numeric queries and stick to debugging my index using Java code.

Nick

sanne.grinovero · **Posted:** Thu May 16, 2013 5:31 am

Hi Nick,
indeed Numeric fields are encoded in a different way and need specific queries, Luke can't be very helpfull as it uses a standard parser which doesn't take field metadata in account. I had not think about it, we'll likely need better tooling to inspect indexes and debug queries..

Is your problem solved? If you make a test case I'm happy to look at it, provided it works out of the box. The easiest way to create a new test is to fork the project from GitHub: https://github.com/hibernate/hibernate-search and follow the README instructions in there.

To create a new test case, it's easy if you find an existing test; we use JUnit and have helpers to quickly setup test databases. Create a new one, commit it to your github repository and send us a link.. if it looks good and you're fine with it we include it in the project.