Updated Date Range to Follow Documentation When Assuming Missing Values#112258
Updated Date Range to Follow Documentation When Assuming Missing Values#112258john-wagster merged 35 commits intoelastic:mainfrom
Conversation
|
Pinging @elastic/es-search-relevance (Team:Search Relevance) |
|
Hi @john-wagster, I've created a changelog YAML for you. |
|
Hi @john-wagster, I've updated the changelog YAML for you. |
…sticsearch into date-range-contains-fix
|
//cc @elastic/es-core-infra This does seem like the way it should have always been for range values :/ wanting to make sure we aren't doing something crazy. |
|
Pinging @elastic/es-search-foundations (Team:Search Foundations) |
|
Hi @john-wagster, I've updated the changelog YAML for you. |
|
Hi @john-wagster, I've updated the changelog YAML for you. |
c8c6d31 to
13e7e00
Compare
…e can go back and fix them; also added a nodefeature as version checks have been disabled
|
@elasticsearchmachine test this please |
| TimeSeriesRoutingHashFieldMapper.TS_ROUTING_HASH_FIELD_PARSES_BYTES_REF, | ||
| FlattenedFieldMapper.IGNORE_ABOVE_WITH_ARRAYS_SUPPORT | ||
| FlattenedFieldMapper.IGNORE_ABOVE_WITH_ARRAYS_SUPPORT, | ||
| RangeFieldMapper.DATE_RANGE_INDEXING_FIX |
There was a problem hiding this comment.
This can be a test feature I think...
There was a problem hiding this comment.
Wasn't sure about when to use test featuers or not; thanks for the suggestion. Let me know if that's not what you were thinking.
…e can go back and fix them; also added a nodefeature as version checks have been disabled
|
Hi @john-wagster, I've updated the changelog YAML for you. |
Relates to #112258
…es (elastic#112258) * updated rangetype to be more inline with the docs (https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-range-query.html) and added tests to reflect as much
Based on a review of the documentation here: https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-range-query.html. Our behavior at query and index time for date range queries was inconsistent.
This would lead to what was discovered here: #111484 where an indexed date_range field like the one shown below would not be returned by the exact same query shown below.
I attempted to fix this by changing the query parser to use DateMathParser which rounds appropriately to what's documented above. This changes missing information in date time values to be inline with the documentation often by 1 millisecond (such as the time information in the below example).
A few concerns worth discussing with this are where this should land in terms of releases and impacts to customer who may have assumptions about how date range has been working up to this point. Opening this as a discussion with some caution around putting it in until we get appropriate feedback.
query example