honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/docs/reference/migration/migrate_7_0/api.asciidoc

105 lines
4.7 KiB
Plaintext
Raw Normal View History

[DOCS] Synchronize location of Breaking Changes (#33588)
2018-09-27 11:41:38 -04:00
[float]
Standardize underscore requirements in parameters (#27414) Stardardize underscore requirements in parameters across different type of requests: _index, _type, _source, _id keep their underscores params like version and retry_on_conflict will be without underscores Throw an error if older versions of parameters are used BulkRequest, MultiGetRequest, TermVectorcRequest, MoreLikeThisQuery were changed Closes #26886
2017-11-17 15:31:52 -05:00
[[breaking_70_api_changes]]
[DOCS] Fixing formatting issues in breaking changes
2018-09-07 19:53:36 -04:00
=== API changes
Standardize underscore requirements in parameters (#27414) Stardardize underscore requirements in parameters across different type of requests: _index, _type, _source, _id keep their underscores params like version and retry_on_conflict will be without underscores Throw an error if older versions of parameters are used BulkRequest, MultiGetRequest, TermVectorcRequest, MoreLikeThisQuery were changed Closes #26886
2017-11-17 15:31:52 -05:00
[DOCS] Synchronize location of Breaking Changes (#33588)
2018-09-27 11:41:38 -04:00
[float]
Standardize underscore requirements in parameters (#27414) Stardardize underscore requirements in parameters across different type of requests: _index, _type, _source, _id keep their underscores params like version and retry_on_conflict will be without underscores Throw an error if older versions of parameters are used BulkRequest, MultiGetRequest, TermVectorcRequest, MoreLikeThisQuery were changed Closes #26886
2017-11-17 15:31:52 -05:00
==== Camel case and underscore parameters deprecated in 6.x have been removed
Using ObjectParser in UpdateRequest (#29293) CRUD: Parsing changes for UpdateRequest (#29293) Use `ObjectParser` to parse `UpdateRequest` so we reject unknown fields and drop support for the `_fields` parameter because it was deprecated in 5.x.
2018-04-16 08:39:35 -04:00
A number of duplicate parameters deprecated in 6.x have been removed from
Standardize underscore requirements in parameters (#27414) Stardardize underscore requirements in parameters across different type of requests: _index, _type, _source, _id keep their underscores params like version and retry_on_conflict will be without underscores Throw an error if older versions of parameters are used BulkRequest, MultiGetRequest, TermVectorcRequest, MoreLikeThisQuery were changed Closes #26886
2017-11-17 15:31:52 -05:00
Bulk request, Multi Get request, Term Vectors request, and More Like This Query
requests.
The following camel case parameters have been removed:
* `opType`
* `versionType`, `_versionType`
The following parameters starting with underscore have been removed:
* `_parent`
* `_retry_on_conflict`
* `_routing`
* `_version`
* `_version_type`
Instead of these removed parameters, use their non camel case equivalents without
starting underscore, e.g. use `version_type` instead of `_version_type` or `versionType`.
[DOCS] Synchronize location of Breaking Changes (#33588)
2018-09-27 11:41:38 -04:00
[float]
Add migration note on thread pool API changes (#29192) A previous change modified the output of the thread pool info contained in the nodes info API. This commit adds a note to the migration docs for this change.
2018-04-28 00:11:17 -04:00
==== Thread pool info
In previous versions of Elasticsearch, the thread pool info returned in the
<<cluster-nodes-info,nodes info API>> returned `min` and `max` values reflecting
the configured minimum and maximum number of threads that could be in each
thread pool. The trouble with this representation is that it does not align with
the configuration parameters used to configure thread pools. For
<<modules-threadpool,scaling thread pools>>, the minimum number of threads is
configured by a parameter called `core` and the maximum number of threads is
configured by a parameter called `max`. For <<modules-threadpool,fixed thread
pools>>, there is only one configuration parameter along these lines and that
parameter is called `size`, reflecting the fixed number of threads in the
pool. This discrepancy between the API and the configuration parameters has been
rectified. Now, the API will report `core` and `max` for scaling thread pools,
and `size` for fixed thread pools.
Similarly, in the cat thread pool API the existing `size` output has been
renamed to `pool_size` which reflects the number of threads currently in the
pool; the shortcut for this value has been changed from `s` to `psz`. The `min`
output has been renamed to `core` with a shortcut of `cr`, the shortcut for
`max` has been changed to `mx`, and the `size` output with a shortcut of `sz`
has been reused to report the configured number of threads in the pool. This
aligns the output of the API with the configuration values for thread
pools. Note that `core` and `max` will be populated for scaling thread pools,
and `size` will be populated for fixed thread pools.
[DOCS] Synchronize location of Breaking Changes (#33588)
2018-09-27 11:41:38 -04:00
[float]
Using ObjectParser in UpdateRequest (#29293) CRUD: Parsing changes for UpdateRequest (#29293) Use `ObjectParser` to parse `UpdateRequest` so we reject unknown fields and drop support for the `_fields` parameter because it was deprecated in 5.x.
2018-04-16 08:39:35 -04:00
==== The parameter `fields` deprecated in 6.x has been removed from Bulk request
and Update request. The Update API returns `400 - Bad request` if request contains
unknown parameters (instead of ignored in the previous version).
Remove the suggest metric from stats APIs (#29635) This metric previously existed for backwards compatibility reasons although the suggest stats were folded into search stats. This metric was deprecated in 6.3.0 and this commit removes them for 7.0.0.
2018-04-24 19:03:48 -04:00
[DOCS] Synchronize location of Breaking Changes (#33588)
2018-09-27 11:41:38 -04:00
[float]
Remove the suggest metric from stats APIs (#29635) This metric previously existed for backwards compatibility reasons although the suggest stats were folded into search stats. This metric was deprecated in 6.3.0 and this commit removes them for 7.0.0.
2018-04-24 19:03:48 -04:00
[[remove-suggest-metric]]
==== Remove support for `suggest` metric/index metric in indices stats and nodes stats APIs
Previously, `suggest` stats were folded into `search` stats. Support for the
`suggest` metric on the indices stats and nodes stats APIs remained for
backwards compatibility. Backwards support for the `suggest` metric was
deprecated in 6.3.0 and now removed in 7.0.0.
In the field capabilities API, remove support for providing fields in the request body. (#30185)
2018-04-27 19:14:11 -04:00
[[remove-field-caps-body]]
In the past, `fields` could be provided either as a parameter, or as part of the request
body. Specifying `fields` in the request body as opposed to a parameter was deprecated
in 6.4.0, and is now unsupported in 7.0.0.
Default copy settings to true and deprecate on the REST layer (#30598) This commit defaults the copy_settings REST parameter to the shrink and split APIs to true, and deprecates the parameter.
2018-05-18 10:12:08 -04:00
[DOCS] Synchronize location of Breaking Changes (#33588)
2018-09-27 11:41:38 -04:00
[float]
Default copy settings to true and deprecate on the REST layer (#30598) This commit defaults the copy_settings REST parameter to the shrink and split APIs to true, and deprecates the parameter.
2018-05-18 10:12:08 -04:00
==== `copy_settings` is deprecated on shrink and split APIs
Versions of Elasticsearch prior to 6.4.0 did not copy index settings on shrink
and split operations. Starting with Elasticsearch 7.0.0, the default behavior
will be for such settings to be copied on such operations. To enable users in
6.4.0 to transition in 6.4.0 to the default behavior in 7.0.0, the
`copy_settings` parameter was added on the REST layer. As this behavior will be
the only behavior in 8.0.0, this parameter is deprecated in 7.0.0 for removal in
8.0.0.
Scripting: Remove support for deprecated StoredScript contexts (#31394) Removes support for storing scripts without the usual json around the script. So You can no longer do: ``` POST _scripts/<templatename> { "query": { "match": { "title": "{{query_string}}" } } } ``` and must instead do: ``` POST _scripts/<templatename> { "script": { "lang": "mustache", "source": { "query": { "match": { "title": "{{query_string}}" } } } } } ``` This improves error reporting when you attempt to store a script but don't quite get the syntax right. Before, there was a good chance that we'd think of it as a "raw" template and just store it. Now we won't do that. Nice.
2018-07-05 09:30:08 -04:00
[DOCS] Synchronize location of Breaking Changes (#33588)
2018-09-27 11:41:38 -04:00
[float]
Scripting: Remove support for deprecated StoredScript contexts (#31394) Removes support for storing scripts without the usual json around the script. So You can no longer do: ``` POST _scripts/<templatename> { "query": { "match": { "title": "{{query_string}}" } } } ``` and must instead do: ``` POST _scripts/<templatename> { "script": { "lang": "mustache", "source": { "query": { "match": { "title": "{{query_string}}" } } } } } ``` This improves error reporting when you attempt to store a script but don't quite get the syntax right. Before, there was a good chance that we'd think of it as a "raw" template and just store it. Now we won't do that. Nice.
2018-07-05 09:30:08 -04:00
==== The deprecated stored script contexts have now been removed
When putting stored scripts, support for storing them with the deprecated `template` context or without a context is
now removed. Scripts must be stored using the `script` context as mentioned in the documentation.
Remove aliases resolution limitations when security is enabled (#31952) Resolving wildcards in aliases expression is challenging as we may end up with no aliases to replace the original expression with, but if we replace with an empty array that means _all which is quite the opposite. Now that we support and serialize the original requested aliases, whenever aliases are replaced we will be able to know what was initially requested. `MetaData#findAliases` can then be updated to not return anything in case it gets empty aliases, but the original aliases were not empty. That means that empty aliases are interpreted as _all only if they were originally requested that way. Relates to #31516
2018-07-20 03:23:32 -04:00
[DOCS] Synchronize location of Breaking Changes (#33588)
2018-09-27 11:41:38 -04:00
[float]
Remove aliases resolution limitations when security is enabled (#31952) Resolving wildcards in aliases expression is challenging as we may end up with no aliases to replace the original expression with, but if we replace with an empty array that means _all which is quite the opposite. Now that we support and serialize the original requested aliases, whenever aliases are replaced we will be able to know what was initially requested. `MetaData#findAliases` can then be updated to not return anything in case it gets empty aliases, but the original aliases were not empty. That means that empty aliases are interpreted as _all only if they were originally requested that way. Relates to #31516
2018-07-20 03:23:32 -04:00
==== Get Aliases API limitations when {security} is enabled removed
The behavior and response codes of the get aliases API no longer vary
depending on whether {security} is enabled. Previously a
404 - NOT FOUND (IndexNotFoundException) could be returned in case the
current user was not authorized for any alias. An empty response with
status 200 - OK is now returned instead at all times.
Security: remove wrapping in put user response (#33512) This change removes the wrapping of the created field in the put user response. The created field was added as a top level field in #32332, while also still being wrapped within the `user` object of the response. Since the value is available in both formats in 6.x, we can remove the wrapped version for 7.0.
2018-09-13 16:40:36 -04:00
[DOCS] Synchronize location of Breaking Changes (#33588)
2018-09-27 11:41:38 -04:00
[float]
Security: remove wrapping in put user response (#33512) This change removes the wrapping of the created field in the put user response. The created field was added as a top level field in #32332, while also still being wrapped within the `user` object of the response. Since the value is available in both formats in 6.x, we can remove the wrapped version for 7.0.
2018-09-13 16:40:36 -04:00
==== Put User API response no longer has `user` object
The Put User API response was changed in 6.5.0 to add the `created` field
outside of the user object where it previously had been. In 7.0.0 the user
object has been removed in favor of the top level `created` field.