Date parsing exception

Elastic Stack Elasticsearch
1

Hello,

When I create an object with a date using the default dynamic mapping
and query this field afterwards with a non-date value, I get a
SearchParseException. Would it be possible to change the behavior
that the query will be simply ignored or my term will be set to a
default value without changing the parseStringValue in the
DateFieldMapper.java ? Could I possibly include my own DateFieldMapper
as a plugin or is there even an easier way to archieve this ?

Many thanks,

Michael

curl -XPUT http://localhost:9200/test/foo/1 -d '{
"start" : "2012-11-15T14:12:12"
}'

curl -XGET http://localhost:9200/test/foo/_search -d '{
"query" : {
"term" : { "start": "bar" }
}
}'

{"error":"SearchPhaseExecutionException[Failed to execute phase
[query_fetch], total failure; shardFailures {[vGv3rzeqQN6wc-boRT_QKg]
[test][0]: SearchParseException[[test][0]: from[-1],size[-1]: Parse
Failure [Failed to parse source [{\n "query" : {\n "term
" : { "start": "bar" }\n }\n}]]]; nested:
MapperParsingException[failed to parse date field, tried both date
format [dateOptionalTime], and timestamp number]; nested:
IllegalArgumentException[Invalid format: "bar"]; }]","status":500}

2

In upcoming 0.19.4, there is support for lenient query_string query (but
not term query, since it is assumed that you know what you do if you build
a term query, I guess):
Query String: Add `lenient` flag to support *value* parse failures · Issue #1932 · elastic/elasticsearch · GitHub.

On Wed, May 16, 2012 at 12:12 PM, mkleen mkleen@gmail.com wrote:

Hello,

When I create an object with a date using the default dynamic mapping
and query this field afterwards with a non-date value, I get a
SearchParseException. Would it be possible to change the behavior
that the query will be simply ignored or my term will be set to a
default value without changing the parseStringValue in the
DateFieldMapper.java ? Could I possibly include my own DateFieldMapper
as a plugin or is there even an easier way to archieve this ?

Many thanks,

Michael

curl -XPUT http://localhost:9200/test/foo/1 -d '{
"start" : "2012-11-15T14:12:12"
}'

curl -XGET http://localhost:9200/test/foo/_search -d '{
"query" : {
"term" : { "start": "bar" }
}
}'

{"error":"SearchPhaseExecutionException[Failed to execute phase
[query_fetch], total failure; shardFailures {[vGv3rzeqQN6wc-boRT_QKg]
[test][0]: SearchParseException[[test][0]: from[-1],size[-1]: Parse
Failure [Failed to parse source [{\n "query" : {\n "term
" : { "start": "bar" }\n }\n}]]]; nested:
MapperParsingException[failed to parse date field, tried both date
format [dateOptionalTime], and timestamp number]; nested:
IllegalArgumentException[Invalid format: "bar"]; }]","status":500}

3

Very nice, this is exactly what I was looking for. Would it make sense to
get a "lenient" parameter also for other queries such as text or term ? I
would love to have this feature without having been forced to use a query
parser. Btw: Do I understand this right that the wildcard support for paths
for the fields such as "fields" : "city.*" is also only supported to have
for the query_string query and not for other queries ?

Thanks for your time,

Michael

On Thursday, May 17, 2012 12:16:33 AM UTC+2, kimchy wrote:

In upcoming 0.19.4, there is support for lenient query_string query (but
not term query, since it is assumed that you know what you do if you build
a term query, I guess):
Query String: Add `lenient` flag to support *value* parse failures · Issue #1932 · elastic/elasticsearch · GitHub.

On Wed, May 16, 2012 at 12:12 PM, mkleen wrote:

Hello,

When I create an object with a date using the default dynamic mapping
and query this field afterwards with a non-date value, I get a
SearchParseException. Would it be possible to change the behavior
that the query will be simply ignored or my term will be set to a
default value without changing the parseStringValue in the
DateFieldMapper.java ? Could I possibly include my own DateFieldMapper
as a plugin or is there even an easier way to archieve this ?

Many thanks,

Michael

curl -XPUT http://localhost:9200/test/foo/1 -d '{
"start" : "2012-11-15T14:12:12"
}'

curl -XGET http://localhost:9200/test/foo/_search -d '{
"query" : {
"term" : { "start": "bar" }
}
}'

{"error":"SearchPhaseExecutionException[Failed to execute phase
[query_fetch], total failure; shardFailures {[vGv3rzeqQN6wc-boRT_QKg]
[test][0]: SearchParseException[[test][0]: from[-1],size[-1]: Parse
Failure [Failed to parse source [{\n "query" : {\n "term
" : { "start": "bar" }\n }\n}]]]; nested:
MapperParsingException[failed to parse date field, tried both date
format [dateOptionalTime], and timestamp number]; nested:
IllegalArgumentException[Invalid format: "bar"]; }]","status":500}

4

Yes, the wildcard aspect is only supported for query_string, as well as
lenient. Its kindda tricky to support it in other elements, since it means
compound queries (ones that inner parse the term query, like bool query)
will need to know how to handle "null" queries.

On Fri, May 18, 2012 at 12:20 PM, Michael Kleen <michael.kleen@numberfour.eu

wrote:

Very nice, this is exactly what I was looking for. Would it make sense to
get a "lenient" parameter also for other queries such as text or term ? I
would love to have this feature without having been forced to use a query
parser. Btw: Do I understand this right that the wildcard support for paths
for the fields such as "fields" : "city.*" is also only supported to have
for the query_string query and not for other queries ?

Thanks for your time,

Michael

On Thursday, May 17, 2012 12:16:33 AM UTC+2, kimchy wrote:

In upcoming 0.19.4, there is support for lenient query_string query (but
not term query, since it is assumed that you know what you do if you build
a term query, I guess): https://github.com/**elasticsearch/elasticsearch/
**issues/1932https://github.com/elasticsearch/elasticsearch/issues/1932
.

On Wed, May 16, 2012 at 12:12 PM, mkleen wrote:

Hello,

When I create an object with a date using the default dynamic mapping
and query this field afterwards with a non-date value, I get a
SearchParseException. Would it be possible to change the behavior
that the query will be simply ignored or my term will be set to a
default value without changing the parseStringValue in the
DateFieldMapper.java ? Could I possibly include my own DateFieldMapper
as a plugin or is there even an easier way to archieve this ?

Many thanks,

Michael

curl -XPUT http://localhost:9200/test/**foo/1http://localhost:9200/test/foo/1-d '{
"start" : "2012-11-15T14:12:12"
}'

curl -XGET http://localhost:9200/test/**foo/_searchhttp://localhost:9200/test/foo/_search-d '{
"query" : {
"term" : { "start": "bar" }
}
}'

{"error":"**SearchPhaseExecutionException[Failed to execute phase
[query_fetch], total failure; shardFailures {[vGv3rzeqQN6wc-boRT_QKg]
[test][0]: SearchParseException[[test][0]: from[-1],size[-1]: Parse
Failure [Failed to parse source [{\n "query" : {\n "term
" : { "start": "bar" }\n }\n}]]]; nested:
MapperParsingException[failed to parse date field, tried both date
format [dateOptionalTime], and timestamp number]; nested:
IllegalArgumentException[**Invalid format: "bar"]; }]","status":500}

5

On Sunday, May 20, 2012 10:22:41 PM UTC+2, kimchy wrote:

Yes, the wildcard aspect is only supported for query_string, as well as
lenient. Its kindda tricky to support it in other elements, since it means
compound queries (ones that inner parse the term query, like bool query)
will need to know how to handle "null" queries.

Oh, does this mean a query_string query should not be used in a compound
query ?

6

On Mon, May 21, 2012 at 10:03 AM, mkleen mkleen@gmail.com wrote:

On Sunday, May 20, 2012 10:22:41 PM UTC+2, kimchy wrote:

Yes, the wildcard aspect is only supported for query_string, as well as
lenient. Its kindda tricky to support it in other elements, since it means
compound queries (ones that inner parse the term query, like bool query)
will need to know how to handle "null" queries.

Oh, does this mean a query_string query should not be used in a compound
query ?

No, thats fine, just the other inner queries... .