Deprecate string in favor of text/keyword.

[jpountz]

This commit removes the ability to use string fields on indices created on or
after 5.0. Dynamic mappings now generate text fields by default for strings
but there are plans to also add a sub keyword field (in a future PR).

Most of the changes in this commit are just about replacing string with
keyword or text. Some tests have been removed because they existed because of
corner cases of string mappings like setting ignore-above on a text field or
enabling term vectors on a keyword field which are now impossible.

The plan is to remove strings entirely in 6.0.

[jpountz]

@rjernst could you have a look?

[rjernst]

Are there any calls to this version of findTemplateBuilder with matchType string? Or findTemplate below? very confusing how we have so many public variants of this method...

[jpountz]

Agreed this should be made simpler.

[rjernst]

LGTM, just one comment which could be addressed in a followup.

[dakrone]

@jpountz I think if this removes string type and throws warnings, it should be marked as breaking and notes added to the migration guide, right?

[jpountz]

I added the breaking label. Regarding documentation, I'm keeping it for later so that the docs can deliver a consistent message about #12394 (I have not documented the text and keyword fields either yet).

[dakrone]

Regarding documentation, I'm keeping it for later so that the docs can deliver a consistent message about #12394 (I have not documented the text and keyword fields either yet).

Makes sense, I just don't want to forget it! :)

[epixa]

With regard to documentation/messaging for this, I just want to underscore how impactful this break can be, so we should make sure to highlight it as clearly as possible when we launch 5.0.

This broke the mappings in Kibana, for example, so all CI builds are breaking and Kibana is uninstallable. We can fix master by updating our mappings for the .kibana index, but in order to support users upgrading their installs after the release, we need to either build into Kibana 5.0 an internal re-indexing feature or change Kibana to use versioned indexes behind a .kibana alias (which is our current consensus).

[rjernst]

@epixa This change is backwards compatible for existing indexes, and users will already need to reindex in order to take advantage of the numeric changes that will also happen in 5.0 (which come with Lucene 6). This only affected kibana tests since it creates new indexes, so I don't see it as a problem?

[Bargs]

I've come across a problem while trying to update the default mappings for the .kibana index.

The current breaking changes guide states:

On all types but string, the index property now only accepts true/false instead of not_analyzed/no. The string field still accepts analyzed/not_analyzed/no

After switching our string field to text, it will now only accept true/false for the index property. How do I get an indexed but not_analyzed text field?

[rjernst]

@Bargs That is what the new keyword type is for, see #16589 for the PR which added it, and #12394 for the meta issue describing the split of string to keyword and text.

[Bargs]

Thanks @rjernst, just the info I needed!

[rashidkpc]

Yeah, we're going to need to build out a reindexing-on-upgrade system in Kibana to support this correctly. We create mappings for Kibana objects on demand, and this is going to cause problems.

For example, if a user has saved dashboards and visualizations, but they've never saved a search they'll have the dashboard and visualization title field set to string. If they then try to save a search we'll try to create a mapping for the search type and that will fail due to a conflict across types.