I've found a strange behavior where if I have an extra field in the
percolator named "type" then range filters on my percolator don't work
properly. See the following test case:
If I change the type field on lines 26 and 74 to "atype" OR change the type
of the "ts" field to "string" on lines 47, 68 and 99 I get results as
expected.
What version of ES are you using? I seem to recall reading about ambiguity
surrounding the use of "type" as a field name in one of the version's
release notes, but I cannot find it quickly now.
However, ES seems to overuse the word "type", referring to both the
document type (roughly analogous to a table) and a field's type (such as
string, long, boolean, and so on). So for the sake of keeping things from
being impossible to explain, I always avoid the use of type for the name of
a type or field. For a worst-case example, "The type of the type field in
type documents is string.". Yikes! It's much better to be able to say
something like "The type of the given_name field in person documents is
string.".
Using 1.0.0. You're probably right but I don't want to go back and change
code in 1000 places if I can avoid it.
On Tuesday, March 4, 2014 4:07:26 PM UTC-8, InquiringMind wrote:
What version of ES are you using? I seem to recall reading about ambiguity
surrounding the use of "type" as a field name in one of the version's
release notes, but I cannot find it quickly now.
However, ES seems to overuse the word "type", referring to both the
document type (roughly analogous to a table) and a field's type (such as
string, long, boolean, and so on). So for the sake of keeping things from
being impossible to explain, I always avoid the use of type for the name of
a type or field. For a worst-case example, "The type of the type field in
type documents is string.". Yikes! It's much better to be able to say
something like "The type of the given_name field in person documents is
string.".
The type top level field is used during registering the query to point to
a mapping. This allows ES to properly resolve field names, so for example
when indexing a query with a range query/filter it can get properly
resolved to a numeric range query if a field is of the type number.
This is documented:
In your can you should either set the type field to trigger or not use it
all. ES should be able to resolve field ts in your query correctly if it
is used in only one mapping.
Using 1.0.0. You're probably right but I don't want to go back and change
code in 1000 places if I can avoid it.
On Tuesday, March 4, 2014 4:07:26 PM UTC-8, InquiringMind wrote:
What version of ES are you using? I seem to recall reading about
ambiguity surrounding the use of "type" as a field name in one of the
version's release notes, but I cannot find it quickly now.
However, ES seems to overuse the word "type", referring to both the
document type (roughly analogous to a table) and a field's type (such as
string, long, boolean, and so on). So for the sake of keeping things from
being impossible to explain, I always avoid the use of type for the name of
a type or field. For a worst-case example, "The type of the type field in
type documents is string.". Yikes! It's much better to be able to say
something like "The type of the given_name field in person documents is
string.".
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.