RE: LongField when searched using classic QueryParser doesnot yield results

Hi,

this is indeed related to this.

The problem is a missing "schema" in Lucene. If you index values using =
several different field types (like TextField vs. =
IntField/Float/Double...) this information how they were indexed is =
completely unknown to the query parser. The default query parser is =
using legacy code to create numeric ranges or numeric terms: It is just =
treating them as text! If it searches on a numeric field using text =
terms, it won't find anything.

Solr and Elasticsearch are maintaining a schema of the index. So they =
subclass the query parser and override getRangeQuery and getFieldQuery =
protected methods and using their schema to create the correct query =
types depending on the schema. The default is to create TermQuery and =
TermRangeQuery, which won't work on numeric fields.

To fix this in your code you have to do something similar. YOU are the =
person who knows what the type of Field XY is. If XY is a numeric field, =
the query parser must check the field name and then build the correct =
query (NumericRangeQuery).

Uwe

-----
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: [email protected]

> -----Original Message-----
> From: Amrit Sarkar [mailto:[email protected]]
> Sent: Wednesday, January 11, 2017 9:52 AM
> To: [email protected]
> Cc: [email protected]
> Subject: Re: LongField when searched using classic QueryParser doesnot =
yield
> results
>=20
> Hi Jaspreet,
>=20
> Not sure whether this helps to answer your question as I didn't try to =
run
> the code:
>=20
> From official guide:
>=20
> > Within Lucene, each numeric value is indexed as a *trie* structure, =
where
> > each term is logically assigned to larger and larger pre-defined =
brackets
> > (which are simply lower-precision representations of the value). The =
step
> > size between each successive bracket is called the precisionStep,
> > measured in bits. Smaller precisionStep values result in larger =
number of
> > brackets, which consumes more disk space in the index but may result =
in
> > faster range search performance. The default value, 4, was selected =
for a
> > reasonable tradeoff of disk space consumption versus performance
>=20
>=20
> > If you only need to sort by numeric value, and never run range
> > querying/filtering, you can index using a precisionStep of
> > Integer.MAX_VALUE
> >
> =
<http://download.oracle.com/javase/6/docs/api/java/lang/Integer.html?is-
> external=3Dtrue#MAX_VALUE>.
> > This will minimize disk space consumed.