…01 which works with date_time and strict_date_time
When data is stored in ElasticSearch, the default mapping is in ISO8601 format, and that is the format the query for a http request comes into the neon server from the neon-gtd. However, it is deserialized into a java Date object (that happens correctly) and then the query is passed off to ElasticSearch. That process calls (clause.rhs as String) which uses the default Java format for dates. ElasticSearch does not understand that by default. This can be fixed by adding a '|E DDD mmm dd, YYYY....etc.' to the mapping.json, and re-indexing but that is not always possible.
the change to ElasticSearch2ConversionStrategyHelper replaces the 'clause.rhs as String' with a function call that checks to see if the rhs is actually a Date, and if so, uses the ISO8601 format.
…01 which works with date_time and strict_date_time
When data is stored in ElasticSearch, the default mapping is in ISO8601 format, and that is the format the query for a http request comes into the neon server from the neon-gtd. However, it is deserialized into a java Date object (that happens correctly) and then the query is passed off to ElasticSearch. That process calls (clause.rhs as String) which uses the default Java format for dates. ElasticSearch does not understand that by default. This can be fixed by adding a '|E DDD mmm dd, YYYY....etc.' to the mapping.json, and re-indexing but that is not always possible.
the change to ElasticSearch2ConversionStrategyHelper replaces the 'clause.rhs as String' with a function call that checks to see if the rhs is actually a Date, and if so, uses the ISO8601 format.