I switched to a range query and expanded the range to 1000 numbers on each
side. I hit the document I expected. Through narrowing the range, I found a
number that the term query will exactly match against the document:
You can see this number is 137 less than the actual number returned in the
document. This number works for both range (with lte and gte both set to
this number) and term queries. What is going on here?
I'm curious about the exact environment you are running these commands
from. I tested it quickly (ES 1.0.1) and it works fine for me from the curl
command-line (i.e. I index the value, it mapped automatically to long, and
queried it back it gave the same value).
I've heard cases where some people executing this in a browser script
environment where big (or small) numbers were not working quite right due
to browser limitations.
I'd double check from the command line to verify if indeed this is the case
for you.
The hit from the command line has the same wrong integer, but I cannot
repeat this problem using a new index. Could it be corruption? Some of my
other indices were corrupted because of node thrashing: new nodes kept
being started after updating to 1.0.1 because I didn't know the command
line options and default behavior were changed (!!!).
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.