Include not analyzed fields in saved objects

[stacey-gammon]

In working on a solution to #10073, I realize we only have an analyzed title field stored in the .kibana index. I don't think it's possible to do an exact match on an analyzed title field.

I can do a match_phrase but it will return more results then I want (e.g. a search for "New" will return "New Visualization"). I can loop through the results manually, but running into this issue makes me think we should change our index to also store raw, not analyzed fields, in case we want to change this in the future.

Thoughts?

/cc @spalger @epixa ... and platform team I guess?

[Bargs]

A multi-field would be nice. I think text was chosen back when the ID matched the title so it didn't matter. A re-index of the .kibana index would be required, so if we were to do this it should be done at the same time we handle the 5.0 -> 6.0 upgrade where strings will be removed.

[spalger]

Yeah, and the default mapping for JSON strings is probably sufficient too, though we should probably rethink the mappings anyway.

[Bargs]

I might be misunderstanding you @spalger, but the JSON fields need to be keyword because they get too long for text. Lukas updated that recently #9353

[spalger]

I meant the default mapping for the strings we send to elasticsearch in the JSON request, which it maps to a text field with a .keyword multi-value field.

[spalger]

I forgot that we are actually defining the mapping for saved object types

[stacey-gammon]

Do we have any plans to add this to 6.0? Turns out that because we limit the # of saved objects retrieved from our loaders, our sorting is broken, and without this, we can't tell elasticsearch to sort on the title field. #11415 (comment)

[Bargs]

@jbudz ^ (since you were working on the static mappings)

[stacey-gammon]

related: #14754

[epixa]

I'm going to close this since I don't think there's anything we'll do globally to address this. Saved object migrations now allow plugins to change their existing mappings, add fields, etc., and the owning plugin for each type of saved object should be making the decisions about how it is stored.

If you still want to use this for warning on name collisions, that should be doable now on a type by type basis, so I recommend opening individual issues for the types you'd like to address.