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

33 lines
1.2 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 support for empty queries (#22092) Our query DSL supports empty queries (`{}`), which have a different meaning depending on the query that holds it, either ignored, match_all or match_none. We deprecated the support for empty queries in 5.0, where we log a deprecation warning wherever they are used. The way we supported it once we moved query parsing to the coordinating node was having an Optional<QueryBuilder> return type in all of our parse methods (called fromXContent). See #17624. The central place for this was QueryParseContext#parseInnerQueryBuilder. We can now remove all the optional return types and simply throw an exception whenever an empty query is found.
2016-12-12 06:37:12 -05:00
* Support for empty query objects (`{ }`) has been removed from the query DSL.
An error is thrown whenever an empty query object is provided.
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.