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/search.asciidoc

30 lines
1.1 KiB
Plaintext
Raw Normal View History

Remove collect payloads parameter The collect_payloads parameter of the span_near query was previously deprecated with the intention to be removed. This commit removes this parameter. Relates #20385
2016-09-08 09:37:36 -04:00
[[breaking_60_search_changes]]
=== Search and Query DSL changes
==== Changes to queries
* The `collect_payloads` parameter of the `span_near` query has been removed. Payloads will be
loaded when needed.
Be strict when parsing values searching for booleans (#21555) This changes only the query parsing behavior to be strict when searching on boolean values. We continue to accept the variety of values during index time, but searches will only be parsed using `"true"` or `"false"`. Resolves #21545
2016-11-15 12:36:57 -05:00
* Queries on boolean fields now strictly parse boolean-like values. This means
only the strings `"true"` and `"false"` will be parsed into their boolean
counterparts. Other strings will cause an error to be thrown.
Remove ignored type parameter in search_shards api (#21688) The `type` parameter has always been accepted by the search_shards api, probably to make the api and its urls the same as search. Truth is that the type never had any effect, it's been ignored from day one while accepting it may make users think that we actually do something with it. This commit removes support for the type parameter from the REST layer and the Java API. Backwards compatibility is maintained on the transport layer though. The new added serialization test also uncovered a bug in the java API where the `ClusterSearchShardsRequest` could be created with no arguments, but the indices were required to be not null otherwise the request couldn't be serialized as `writeTo` would throw NPE. Fixed by setting a default value (empty array) for indices.
2016-11-22 11:22:33 -05:00
[DOCS] document breaking changes added with #21852
2016-11-29 14:05:04 -05:00
* The `in` query (a synonym for the `terms` query) has been removed
* The `geo_bbox` query (a synonym for the `geo_bounding_box` query) has been removed
* The `mlt` query (a synonym for the `more_like_this` query) has been removed
* The `fuzzy_match` and `match_fuzzy` query (synonyma for the `match` query) have been removed
Remove ignored type parameter in search_shards api (#21688) The `type` parameter has always been accepted by the search_shards api, probably to make the api and its urls the same as search. Truth is that the type never had any effect, it's been ignored from day one while accepting it may make users think that we actually do something with it. This commit removes support for the type parameter from the REST layer and the Java API. Backwards compatibility is maintained on the transport layer though. The new added serialization test also uncovered a bug in the java API where the `ClusterSearchShardsRequest` could be created with no arguments, but the indices were required to be not null otherwise the request couldn't be serialized as `writeTo` would throw NPE. Fixed by setting a default value (empty array) for indices.
2016-11-22 11:22:33 -05:00
The `terms` query should always map to a Lucene `TermsQuery`. (#21786) Currently, the `terms` query is just syctactic sugar for a `bool` query when used in a query context. This change proposes to always generate the same query in query and filter contexts, which is less confusing.
2016-11-30 09:29:09 -05:00
* The `terms` query now always returns scores equal to `1` and is not subject to
`indices.query.bool.max_clause_count` anymore.
Remove indices query (#21837) The indices query is deprecated since 5.0.0 (#17710). It can now be removed in master (future 6.0 version).
2016-11-30 13:37:01 -05:00
* The deprecated `indices` query has been removed.
Remove ignored type parameter in search_shards api (#21688) The `type` parameter has always been accepted by the search_shards api, probably to make the api and its urls the same as search. Truth is that the type never had any effect, it's been ignored from day one while accepting it may make users think that we actually do something with it. This commit removes support for the type parameter from the REST layer and the Java API. Backwards compatibility is maintained on the transport layer though. The new added serialization test also uncovered a bug in the java API where the `ClusterSearchShardsRequest` could be created with no arguments, but the indices were required to be not null otherwise the request couldn't be serialized as `writeTo` would throw NPE. Fixed by setting a default value (empty array) for indices.
2016-11-22 11:22:33 -05:00
==== Search shards API
The search shards API no longer accepts the `type` url parameter, which didn't
have any effect in previous versions.