Automatically add a sub keyword field to string dynamic mappings.

[jpountz]

If you add a string field to a document, it will have the following default
mapping:

{
  "type": "text",
  "fields": {
    "keyword": {
      "type": "keyword",
      "ignore_above": 256
    }
  }
}

[rjernst]

Is the intention here supposed to be to allow users to use aggregations on any json string "by default"? This means the data would then be indexed 3 times, once in the field, once in _all, and once in the keyword subfield. If I was correct above, then do we really need this subfield to be indexed, or could it just be there for doc values? I'm also more of a fan of "original" then for the name.

[jpountz]

Your assumptions are correct. Indexing the sub field is useful so that if the user runs eg. a terms aggregations to build a pie chart, then we can build a filter on the same field when (s)he clicks on one piece of the chart. If we were to do it with the text field, we might also match values that have a different case for instance.

I used "keyword" because it was the suggested name on #12394 (see "Good out-of-the-box dynamic mappings for string fields").

[clintongormley]

Personally I'm a fan of keyword as it says "this is the keyword variant of the main field". That said, Logstash has used raw for a long time, as has our documentation.

If we were to use keyword as the default name, Logstash could continue to use raw in the Logstash template to maintain bwc, but I'm guessing that Logstash would prefer to use our defaults instead. I'd rather make the right choice for the future, rather than using raw just for historical reasons, but I'm not sure that the choice between keyword vs raw is that clear cut.

Opinions welcome.

[jpountz]

Should we merge it as-is so that this feature would be included in the alpha releases and we have feedback about this multi-field mapping by default? Then we can open a blocker issue about whether we want to change the naming for the GA.

[rjernst]

+1 to merge

[djschny]

Do we really want to couple the name of the mult-field to the the analyzer type? keyword analzyer really should be called noop anyway because that is how it behaves and we even explain it that way to people.

[jpountz]

@djschny I believe the idea was more to couple it with the field type than the analyzer type. Please open a new issue if you think this should be changed to something else.