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_6_0/rest.asciidoc

56 lines
2.4 KiB
Plaintext
Raw Normal View History

Remove allow unquoted JSON Previous versions of Elasticsearch permitted unquoted JSON field names even though this is against the JSON spec. This leniency was disabled by default in the 5.x series of Elasticsearch but a backwards compatibility layer was added via a system property with the intention of removing this layer in 6.0.0. This commit removes this backwards compatibility layer. Relates #20388
2016-09-08 13:36:31 -04:00
[[breaking_60_rest_changes]]
=== REST changes
==== Unquoted JSON
In previous versions of Elasticsearch, JSON documents were allowed to contain unquoted field names.
Fixed typos (#20843)
2016-10-10 16:51:47 -04:00
This feature was removed in the 5.x series, but a backwards-compatibility layer was added via the
system property `elasticsearch.json.allow_unquoted_field_names`. This backwards-compatibility layer
Remove allow unquoted JSON Previous versions of Elasticsearch permitted unquoted JSON field names even though this is against the JSON spec. This leniency was disabled by default in the 5.x series of Elasticsearch but a backwards compatibility layer was added via a system property with the intention of removing this layer in 6.0.0. This commit removes this backwards compatibility layer. Relates #20388
2016-09-08 13:36:31 -04:00
has been removed in Elasticsearch 6.0.0.
Removing request parameters in _analyze API Remove unused imports Replace POST method by GET method in docs Add breaking changes explanation Fix small issue in Kuromoji docs Closes #20246
2016-09-30 16:42:45 -04:00
Enable strict duplicate checks for all XContent types (#22225) With this commit we enable the Jackson feature 'STRICT_DUPLICATE_DETECTION' by default for all XContent types (not only JSON). We have also changed the name of the system property to disable this feature from `es.json.strict_duplicate_detection` to the now more appropriate name `es.xcontent.strict_duplicate_detection`. Relates elastic/elasticsearch#19614 Relates elastic/elasticsearch#22073
2016-12-19 03:29:47 -05:00
==== Duplicate Keys in JSON, CBOR, Yaml and Smile
Enable strict duplicate checks for JSON content With this commit we enable the Jackson feature 'STRICT_DUPLICATE_DETECTION' by default. This ensures that JSON keys are always unique. While this has a performance impact, benchmarking has indicated that the typical drop in indexing throughput is around 1 - 2%. As a last resort, we allow users to still disable strict duplicate checks by setting `-Des.json.strict_duplicate_detection=false` which is intentionally undocumented. Closes #19614
2016-12-14 03:35:53 -05:00
Enable strict duplicate checks for all XContent types (#22225) With this commit we enable the Jackson feature 'STRICT_DUPLICATE_DETECTION' by default for all XContent types (not only JSON). We have also changed the name of the system property to disable this feature from `es.json.strict_duplicate_detection` to the now more appropriate name `es.xcontent.strict_duplicate_detection`. Relates elastic/elasticsearch#19614 Relates elastic/elasticsearch#22073
2016-12-19 03:29:47 -05:00
In previous versions of Elasticsearch, documents were allowed to contain duplicate keys. Elasticsearch 6.0.0
enforces that all keys are unique. This applies to all content types: JSON, CBOR, Yaml and Smile.
Enable strict duplicate checks for JSON content With this commit we enable the Jackson feature 'STRICT_DUPLICATE_DETECTION' by default. This ensures that JSON keys are always unique. While this has a performance impact, benchmarking has indicated that the typical drop in indexing throughput is around 1 - 2%. As a last resort, we allow users to still disable strict duplicate checks by setting `-Des.json.strict_duplicate_detection=false` which is intentionally undocumented. Closes #19614
2016-12-14 03:35:53 -05:00
Optionally require a valid content type for all rest requests with content (#22691) This change adds a strict mode for xcontent parsing on the rest layer. The strict mode will be off by default for 5.x and in a separate commit will be enabled by default for 6.0. The strict mode, which can be enabled by setting `http.content_type.required: true` in 5.x, will require that all incoming rest requests have a valid and supported content type header before the request is dispatched. In the non-strict mode, the Content-Type header will be inspected and if it is not present or not valid, we will continue with auto detection of content like we have done previously. The content type header is parsed to the matching XContentType value with the only exception being for plain text requests. This value is then passed on with the content bytes so that we can reduce the number of places where we need to auto-detect the content type. As part of this, many transport requests and builders were updated to provide methods that accepted the XContentType along with the bytes and the methods that would rely on auto-detection have been deprecated. In the non-strict mode, deprecation warnings are issued whenever a request with body doesn't provide the Content-Type header. See #19388
2017-02-02 14:07:13 -05:00
==== Content-Type Auto-detection
In previous versions of Elasticsearch, having a proper Content-Type for the data in a request was not enforced.
Elasticsearch 6.0.0 enforces that all requests with a body must have a supported Content-Type and this type will
be used when parsing the data.
Enforce Content-Type requirement on the rest layer and remove deprecated methods (#23146) This commit enforces the requirement of Content-Type for the REST layer and removes the deprecated methods in transport requests and their usages. While doing this, it turns out that there are many places where *Entity classes are used from the apache http client libraries and many of these usages did not specify the content type. The methods that do not specify a content type explicitly have been added to forbidden apis to prevent more of these from entering our code base. Relates #19388
2017-02-17 14:45:41 -05:00
When using the `source` query string parameter, the `source_content_type` parameter must also be specified with
the media type of the source.
Make boolean conversion strict (#22200) This PR removes all leniency in the conversion of Strings to booleans: "true" is converted to the boolean value `true`, "false" is converted to the boolean value `false`. Everything else raises an error.
2017-01-19 01:59:18 -05:00
==== Boolean API parameters
All REST APIs parameters (both request parameters and JSON body) support providing boolean "false" as the
value `false` and boolean "true" as the value `true`. All other values will raise an error.
Removing request parameters in _analyze API Remove unused imports Replace POST method by GET method in docs Add breaking changes explanation Fix small issue in Kuromoji docs Closes #20246
2016-09-30 16:42:45 -04:00
==== Analyze API changes
Deprecating request parameters in _analyze API Remove params in indices.analyze.json Fix REST changes Closes #20246
2016-10-05 06:13:33 -04:00
The deprecated request parameters and plain text in request body has been removed. Define parameters in request body.
Remove support for controversial ignore_unavailable and allow_no_indices from indices exists api (#20712) Exist requests are supposed to never throw an exception, but rather return true or false depending on whether some resource exists or not. Indices exists does that for indices and accepts wildcard expressions too. The way the api works internally is by resolving indices and catching IndexNotFoundException: if an exception is thrown the index does not exist hence it returns false, otherwise it returns true. That works ok only if ignore_unavailable and allow_no_indices indices options are both set to false, meaning that they are strict and any missing index or wildcard expressions that resolves to no indices will lead to an exception that can be thrown and cause false to be returned. Unfortunately the indices options have been configurable up until now for this request, meaning that one can set ignore_unavailable or allow_no_indices to true and have the indices exist request return true for indices that really don't exist, which makes very little sense in the context of this api. This commit removes the indicesOptions setter from the IndicesExistsRequest and makes settable only expandWildcardsOpen and expandWildcardsClosed, hence a subset of the available indices options. This way we can guarantee more consistent behaviour of the indices exists api. We can then remove the ignore_unavailable and allow_no_indices option from indices exists api spec
2016-11-04 14:26:37 -04:00
==== Indices exists API
The `ignore_unavailable` and `allow_no_indices` options are no longer accepted
as they could cause undesired results when their values differed from their
defaults.
Remove 2.x backward compatibility of mappings. (#21670) For the record, I also had to remove the geo-hash cell and geo-distance range queries to make the code compile. These queries already throw an exception in all cases with 5.x indices, so that does not hurt any more. I also had to rename all 2.x bwc indices from `index-${version}` to `unsupported-${version}` to make `OldIndexBackwardCompatibilityIT` happy.
2016-11-30 07:34:46 -05:00
Change certain replica failures not to fail the replica shard This changes the way that replica failures are handled such that not all failures will cause the replica shard to be failed or marked as stale. In some cases such as refresh operations, or global checkpoint syncs, it is "okay" for the operation to fail without the shard being failed (because no data is out of sync). In these cases, instead of failing the shard we should simply fail the operation, and, in the event it is a user-facing operation, return a 5xx response code including the shard-specific failures. This was accomplished by having two forms of the `Replicas` proxy, one that is for non-write operations that does not fail the shard, and one that is for write operations that will fail the shard when an operation fails. Relates to #10708
2017-01-16 12:46:12 -05:00
==== `timestamp` and `ttl` in index requests
Remove 2.x backward compatibility of mappings. (#21670) For the record, I also had to remove the geo-hash cell and geo-distance range queries to make the code compile. These queries already throw an exception in all cases with 5.x indices, so that does not hurt any more. I also had to rename all 2.x bwc indices from `index-${version}` to `unsupported-${version}` to make `OldIndexBackwardCompatibilityIT` happy.
2016-11-30 07:34:46 -05:00
`timestamp` and `ttl` are not accepted anymore as parameters of index/update
Change certain replica failures not to fail the replica shard This changes the way that replica failures are handled such that not all failures will cause the replica shard to be failed or marked as stale. In some cases such as refresh operations, or global checkpoint syncs, it is "okay" for the operation to fail without the shard being failed (because no data is out of sync). In these cases, instead of failing the shard we should simply fail the operation, and, in the event it is a user-facing operation, return a 5xx response code including the shard-specific failures. This was accomplished by having two forms of the `Replicas` proxy, one that is for non-write operations that does not fail the shard, and one that is for write operations that will fail the shard when an operation fails. Relates to #10708
2017-01-16 12:46:12 -05:00
requests.
==== Refresh requests with one or more shard failures return HTTP 500 response instead of 200
Refresh requests that are broadcast to multiple shards that can have one or more
shards fail during the request now return a 500 response instead of a 200
response in the event there is at least one failure.
Require explicit query in _delete_by_query API (#23632) As the query of a search request defaults to match_all, calling _delete_by_query without an explicit query may result in deleting all data. In order to protect users against falling into that pitfall, this commit adds a check to require the explicit setting of a query. Closes #23629
2017-03-28 10:44:57 -04:00
=== Delete by Query API requires an explicit query
In previous versions of Elasticsearch, delete by query requests without an explicit query
were accepted, match_all was used as the default query and all documents were deleted
as a result. From version 6.0.0, delete by query requests require an explicit query.