Continue to use .raw instead of .keyword

[clintongormley]

Hi all

We discussed the issue of renaming .raw to .keyword fields in the Elasticsearch FixItFriday again today. I thought that field aliases (elastic/elasticsearch#17511) might possibly be a solution to help with the transition. We even considered adding a dedicated hack to automatically check for a .raw field if a .keyword field didn't exist.

Unfortunately we didn't come up with a good solution.

We're aware of the impact that this rename will have on our users and want to suggest that you reconsider the change in #462

In Elasticsearch, naming the field .keyword makes sense given our variety of use cases, but Logstash solves a much more focused problem. A .raw field HAS made sense in the past and will continue to make sense in Logstash's future. There's no real reason to change - I think it is OK to deviate from the Elasticsearch default here.

It's certainly an easy way of removing a large obstacle from the upgrade path.

/cc @tsg @monicasarbu

[monicasarbu]

Thanks for the heads up. I think this doesn't affect Beats, because we define the type of each exported field, so normally there is no .keyword created in Elasticsearch. We also didn't use .raw before.

[monicasarbu]

This might affect Add-data UI. /cc @Bargs

[suyograo]

See #474 (comment), we are sticking to .keyword instead of .raw. This will not be a painful upgrade because we don't force update the template for existing users.