-
Notifications
You must be signed in to change notification settings - Fork 25k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
datehistogram sometimes ignores format when searching on multiple indexes #31760
Comments
Pinging @elastic/es-search-aggs |
@plaarakkers Sorry for the long wait on this, this issue somehow slipped our attention although the reproduction in the test is really great. |
I opened #35254 which should at least fix the cases where the "format" is explicitely specified in the aggregation itself. I'm not sure we can reliably fix the case where the format is only specified on one index but the other indexs date field is "unmapped", because I don't think we cannot reliably determine the "winning" format in the aggregation. Maybe we can add a special case for this in the reduce phase somewhere, though I'm not sure about this yet. |
Currently when aggregating on an unmapped date field (e.g. using a date_histogram) we don't preserve the aggregations `format` setting but instead use the default format. This can lead to loosing the aggregations `format` when aggregating over several indices where some of them contain unmapped date fields and are encountered first in the reduce phase. Related to elastic#31760
…35254) Currently when aggregating on an unmapped date field (e.g. using a date_histogram) we don't preserve the aggregations `format` setting but instead use the default format. This can lead to loosing the aggregations `format` when aggregating over several indices where some of them contain unmapped date fields and are encountered first in the reduce phase. Related to #31760
…35254) Currently when aggregating on an unmapped date field (e.g. using a date_histogram) we don't preserve the aggregations `format` setting but instead use the default format. This can lead to loosing the aggregations `format` when aggregating over several indices where some of them contain unmapped date fields and are encountered first in the reduce phase. Related to #31760
…35254) Currently when aggregating on an unmapped date field (e.g. using a date_histogram) we don't preserve the aggregations `format` setting but instead use the default format. This can lead to loosing the aggregations `format` when aggregating over several indices where some of them contain unmapped date fields and are encountered first in the reduce phase. Related to #31760
@plaarakkers The fix mentioned above (#35254) should solve the cases you mentioned where the aggregation specifies a specific format. For the other case (two indices havinf different formats in the mappings, or one missing - which means the same as the default format) we haven't really got a good way of deciding which one should "win". I think the fact you observe that the order of index names matters is just coincidental. When merging aggregation results from different shards and indices we use the format of whatever results returns first to the coordinating node. The only way to make sure the format is deterministic is to either make sure the same format is specified in all mappings or explicitly set it on the aggregation. |
Closing, please reopen if you see the need for further action. |
Elasticsearch version (Version: 6.3.0 (docker image based on docker.elastic.co/elasticsearch/elasticsearch:6.3.0)):
Plugins installed: []
JVM version (client build 1.8.0_171-b11):
OS version (Linux 4.15.0-23-generic):
Description of the problem including expected versus actual behavior:
The date histogram ignores the format of the aggregation or date field
if the search is performed on multiple indexes where the alphabetically first index does not contain the date field. This results in an unexpected value for the key_as_string in the bucket
Steps to reproduce:
I created a unit test to reproduce the issue. This uses the following mappings:
searchIndexWithDateField.json
searchIndexWithoutDateField.json
The unit test itself uses version 6.3.0 for the java client maven dependencies:
The output of these tests are:
You can see that the output for testAggregationFormatIncorrect and testDateFieldFormatIncorrect uses the default date format while the only difference is that the names of the indexes are switched.
I would expect that the output would be the same for all test cases.
The text was updated successfully, but these errors were encountered: