there are already a few "bug"-reports about this, but I couldn't find an
official statement, if it is intended design or a bug.
If you use a numeric range filter on an unmapped field, you will get a
exception like this:
org.elasticsearch.index.query.QueryParsingException: [default] failed to
find mapping for field [dateUnmapped]
at
org.elasticsearch.index.query.NumericRangeFilterParser.parse(NumericRangeFilterParser.java:115)
~[elasticsearch-0.20.5.jar:na]
at
org.elasticsearch.index.query.QueryParseContext.parseInnerFilter(QueryParseContext.java:225)
~[elasticsearch-0.20.5.jar:na]
at
org.elasticsearch.index.query.ConstantScoreQueryParser.parse(ConstantScoreQueryParser.java:68)
~[elasticsearch-0.20.5.jar:na]
For me it's more a bug than a feature, because the other filters are
working on unmapped fields without problems.
If there are no plans to change the behavior of numeric range filters, then
I think the only solution for our
application is to define all mappings manually and don't let elasticsearch
create the mappings dynamically.
I suspect that if you only load numeric data into a field, ES will
dynamically map it as a numeric field. But then again, I have loaded
10-digit NANP telephone numbers (all digits) into fields and they were
dynamically mapped as a string field. So I'm not really sue.
The best advice I've seen is that ES dynamic mapping is great for getting
started and coming up to speed. But for deterministic behavior in a
production application, you should always create explicit settings+mappings
in each index before you put data into that index. For my own ease of
experimentation and development, I defined a simple "schema" that embodies
the subset of ES mapping functions that I need, and then a tool to create
the settings and mappings based on that "schema". It has greatly helped me
keep my sanity!
And starting with ES 20, I read that you can direct ES to fail to load any
document with an unmapped field.
Also note that one great side benefit to explicit mapping is to define
multi-field mapping in which a field can be both a string and a number (for
example). So you can issue prefix queries on the string for, and range
filters against the numeric form. Bloats the index a little, but the exact
same source is used. As one example.
On Monday, March 18, 2013 10:28:09 AM UTC-4, dawi wrote:
Hi together,
For me it's more a bug than a feature, because the other filters are
working on unmapped fields without problems.
If there are no plans to change the behavior of numeric range filters,
then I think the only solution for our
application is to define all mappings manually and don't let elasticsearch
create the mappings dynamically.
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.