-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Mappings: Deprecate index_name
and path
#6677
Comments
++ |
huge +1 IMO we should start rejecting this setting on new created indices! |
Yes! Deprecate in 1.3 and remove in master? |
the removal is a problem IMO since this is a index level BWC issue :/ |
index_name
sindex_name
and path
The
From 3.0:
|
For your consideration, please review this issue. Perhaps removing index_name will have a greater impact than intended. |
In 2.0, I think we can upgrade the mapping in a way that is not perfect, but will cover most use cases and help users to upgrade without reindexing.
We can't distinguish between these two use cases automatically, but we can handle the first use case gracefully, and the second use case is an easy change to make application side (ie just change all use of A mapping that looks like this (with
could be rewritten to:
The mapping for the new In the case where
could be rewritten as:
|
object/nested fields or index_name in any field Backcompat is still here for indexes created before 2.0. closes elastic#6677
Today we allow for custom index names. This adds ambiguity as fields might be referred to either according to their index name or their field name. What should happen when several fields have the same index name or if the index name of a field is the same as the full name of another field?
My understanding is that custom
index_name
s are not useful anymore now that we havecopy_to
in order to index several logical fields into a single physical one, so I'd like to deprecate customindex_name
s so that the index name would always be the same as the full name.Relates to #4081, #8870
The text was updated successfully, but these errors were encountered: