Skip to content

revert to use .raw instead of .keyword #474

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

Closed
wants to merge 1 commit into from

Conversation

suyograo
Copy link
Contributor

@suyograo suyograo commented Sep 8, 2016

In PR #462 (comment)
we used .keyword to match ES's change in default behavior.

Both approaches, using .keyword to match ES for consistency and using .raw to match
existing logstash data has pros/cons. I think at this time it is wise to err on the side of
easy-upgrade-path for users so reverting template back to using .raw as before

Fixes #466

In PR logstash-plugins#462 (comment)
we used `.keyword` to match ES's change in default behavior.

Both approaches, using `.keyword` to match ES for consistency and using `.raw` to match
existing logstash data has pros/cons. I think at this time it is wise to err on the side of
easy-upgrade-path so reverting this back to using `.raw` as before

Fixes logstash-plugins#466
@jordansissel
Copy link
Contributor

I think @clintongormley's notes about the impact on various user groups are good reference here: elastic/elasticsearch#18195 (comment)

I believe existing users (with or without default settings) will be unaffected by the .keyword change until they elect to change from .raw to .keyword. New users will start with .keyword. This seems safe-enough to me.

I hope moving from .raw to .keyword is not a painful transition. I am confident that we understand the impact to each group of users.

As discussed offline, I"ll close this. <3

@T3rm1
Copy link

T3rm1 commented Feb 6, 2018

I have this problem now. Upgraded from 5 to 6 and with the new default template .keyword is used instead of .raw. So every new index uses keyword while tons of old indices use raw. What do you suggest to do in that case?

@andrewvc
Copy link
Contributor

andrewvc commented Feb 7, 2018

@T3rm1 have you considered using a custom template? That way you can control the field names exactly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants