Allow strings in date range aggregation

[pquentin]

Should fix the following test:

// Test file: /test/free/aggregations/range.yml
// Test name: Range aggregation on date field

import { expectAssignable } from 'tsd'
import * as T from '../types'

expectAssignable<T.SearchRequest>({
  "body": {
    "aggs": {
      "date_range": {
        "range": {
          "field": "date",
          "ranges": [
            {
              "from": "2021-05-01T00:00:00Z",
              "to": "2021-05-05T00:00:00Z"
            }
          ]
        }
      }
    },
    "size": 0
  },
  "index": "date_range_test",
  "typed_keys": true
})

[github-actions]

Following you can find the validation changes against the target branch for the API.

API	Status	Request	Response
search	🔴	2651/2669 → 2652/2669	2669/2669

You can validate this API yourself by using the make validate target.

[flobernd]

Let me check the consequences of this change for the .NET client please, before you merge it.

FieldValue does not look like the best candidate here at a first glance. Would DateTime work? If I remember correctly this type alles string and timestamp representation. However, not sure why the range was a double before. AFAIK we do have double timestamp types as well, but not yet a combined version like DateTime.

We should probably introduce a new type of DateTime does not fit, to allow statically typed languages to use their native DateTime primitives like we do in all other cases that deal with date/time values.

[flobernd]

Ok, so I checked this in detail and I think the test is simply not valid.

"aggs": {
  "date_range": {
    "range": {

This part makes no sense. date_range does not support a range field. It supports ranges which is correctly typed as ranges?: DateRangeExpression[] and therefore supports both representations (double and string).

The AggregationRange type you changed in this PR is used by GeoDistanceAggregation and the regular RangeAggregation but does not affect DateRangeAggregation.

WDYT @l-trotta @Anaethelion ?

[l-trotta]

@flobernd this is not a date_range aggregation... it's a range aggregation, named "date_range" ^^" still, I also think this test is wrong, I can find no evidence server side that from and to can be strings in the context of range aggregation

[flobernd]

Ah right, the first key is the name of the aggregation. Confusing 😵‍💫

[l-trotta]

had to stare at it for a good 2 minutes

[flobernd]

@pquentin @l-trotta

I can find no evidence server side that from and to can be strings in the context of range aggregation

Should we remove the faulty test instead?

[pquentin]

This was fixed intentionally in elastic/elasticsearch#82732

I can skip the test, but Elasticsearch does accept this query:

{
  "api": "search",
  "file": "/test/free/aggregations/range.yml",
  "name": "Range aggregation on date field",
  "origin": "yaml",
  "request": {
    "args": {
      "body": {
        "aggs": {
          "date_range": {
            "range": {
              "field": "date",
              "ranges": [
                {
                  "from": "2021-05-01T00:00:00Z",
                  "to": "2021-05-05T00:00:00Z"
                }
              ]
            }
          }
        },
        "size": 0
      },
      "index": "date_range_test",
      "typed_keys": true
    }
  },
  "response": {
    "headers": {
      "content-type": "application/json",
      "transfer-encoding": "chunked",
      "x-elastic-product": "Elasticsearch"
    },
    "payload": {
      "_shards": {
        "failed": 0,
        "skipped": 0,
        "successful": 1,
        "total": 1
      },
      "aggregations": {
        "range#date_range": {
          "buckets": [
            {
              "doc_count": 4,
              "from": 1619827200000,
              "from_as_string": "2021-05-01T00:00:00.000Z",
              "key": "2021-05-01T00:00:00.000Z-2021-05-05T00:00:00.000Z",
              "to": 1620172800000,
              "to_as_string": "2021-05-05T00:00:00.000Z"
            }
          ]
        }
      },
      "hits": {
        "hits": [
        ],
        "max_score": null,
        "total": {
          "relation": "eq",
          "value": 5
        }
      },
      "timed_out": false,
      "took": 1
    },
    "statusCode": 200
  }
}

[flobernd]

Let's discuss this in the next specification meeting @pquentin 🙂

I think to make this perfect, we have so use untyped variant like for RangeQuery.