Only issue a deprecation warning if include_type_name is not set. #38825
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We expect many users to have a custom document type in 6.x, for example they might have used `doc` when creating indices. In this case, users cannot easily switch over to typeless index creations in 6.7 using `include_type_name=false`, because the rest of their document CRUD calls will refer to the custom type. Instead, we are recommending that users take the following steps: set `include_type_name=true` in 6.7 for all relevant calls, upgrade to 7.0, then switch over completely to the typeless APIs and stop using `include_type_name`. This means that it will be very common to set `include_type_name=true` in 6.7, so it is misleading to emit a deprecation warning to tell the user to switch to using `include_type_name=false`. This PR switches to emitting a deprecation warning only if `include_type_name` is not set at all. The warning serves as an important note to users that the request and response format of these APIs will change in a breaking way in 7.0.
|
Pinging @elastic/es-search |
jpountz
approved these changes
Feb 13, 2019
jtibshirani
added a commit
to jtibshirani/elasticsearch
that referenced
this pull request
Feb 13, 2019
Follow-up to elastic#38825, where we made a tweak to the deprecation behavior.
| "mapping requests will change in 7.0. Please start using the include_type_name parameter set to false " + | ||
| "to move to the new, typeless response format that will become the default."; | ||
| static final String TYPES_DEPRECATION_MESSAGE = "[types removal] The parameter include_type_name " + | ||
| "should be explicitly specified in get index requests to prepare for 7.0. In 7.0 include_type_name " + |
There was a problem hiding this comment.
get index requests
@jtibshirani should it be "get field mapping requests"?
There was a problem hiding this comment.
Thanks @mayya-sharipova, will fix. I somehow make this mistake every time...
jtibshirani
added a commit
that referenced
this pull request
Feb 13, 2019
Follow-up to #38825, where we made a tweak to the deprecation behavior.
jtibshirani
added a commit
that referenced
this pull request
Feb 13, 2019
Follow-up to #38825, where we made a tweak to the deprecation behavior.
jtibshirani
added a commit
that referenced
this pull request
Feb 13, 2019
Follow-up to #38825, where we made a tweak to the deprecation behavior.
jtibshirani
added a commit
that referenced
this pull request
Feb 13, 2019
Follow-up to #38825, where we made a tweak to the deprecation behavior.
jtibshirani
added a commit
that referenced
this pull request
Feb 13, 2019
Follow-up to #38825, where we made a tweak to the deprecation behavior.
jtibshirani
added a commit
that referenced
this pull request
Feb 13, 2019
Follow-up to #38825, where we made a tweak to the deprecation behavior.
jtibshirani
added a commit
that referenced
this pull request
Jun 30, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We expect many users to have a custom document type in 6.x, for example they
might have used
docwhen creating indices. In this case, users cannot easilyswitch over to typeless index creations in 6.7 using
include_type_name=false,because the rest of their document CRUD calls will refer to the custom type.
Instead, we are recommending that users take the following steps: set
include_type_name=truein 6.7 for all relevant calls, upgrade to 7.0, thenswitch over completely to the typeless APIs and stop using
include_type_name.This means that it will be very common to set
include_type_name=truein 6.7,so it is misleading to emit a deprecation warning to tell the user to switch to
using
include_type_name=false. This PR switches to emitting a deprecationwarning only if
include_type_nameis not set at all. The warning serves as animportant note to users that the request and response format of these APIs will
change in a breaking way in 7.0.
Relates to #35190.