Use elasticsearch's key_as_string to display field-values

[thomasneirynck]

ES responses include the key_as_string values when aggregating results. This is a human readable version of the field-value.

For example:

• booleans: ES aggregates results under '0' and '1' for booleans, but maps these to 'true' and 'false' under the key_as_string property.
• dates: cf. https://www.elastic.co/guide/en/elasticsearch/reference/2.3/search-aggregations-bucket-datehistogram-aggregation.html#_keys

Kibana currently does not use the key_as_string value at all.

Kibana has a separate formatting layer: field formatters. These can be applied to one or more field-types.

• Are we unnecessarily duplicating functionality?
• What is the added value of field formatters when ES already returns pre-formatted strings?
• Should Kibana use key_as_string as the default way of showing a field-value? Or in the absence of a field formatter?
• Is the key_as_string-value sufficient to eliminate simple field-formatters? See also Add Boolean field formatter #7935, which introduces a Boolean field formatter so Kibana pretty-prints booleans for legends and axis.

[3ygun]

A field formatter functionality that is commonly used as a Kibana user is the ability to specify the precision of a number.

If Kibana were to move away from field formatters to the key_as_string does Elasticsearch already provide this kind of functionality to define what the key_as_string should appear like?

I would think using key_as_string as the default behavior would be useful as less client side work would need to be done to format the data. However, unless the above is accessible, a full conversion away from field formatters would be bad.

[thomasneirynck]

Hi @3ygun,

thanks for the feedback. I agree with you on the usefulness of field formatters, and I expect them to remain in Kibana.

I opened this issue more to get a better understanding whether the key_as_string functionality from ES is underused in Kibana. Right now, Kibana just plains ignores it, which may be too drastic.

[epixa]

It looks like *_as_string may be removed in 6.0 and there isn't a lot of demand for this anyway, so let's close this for now.

See elastic/elasticsearch#18518