NumericRangeFilter: failed to find mapping for field

Hi together,

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]

The following posts go into the same direction:

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.

Or am I missing something?

Regards,
Daniel

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Daniel,

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.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.