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

88 lines
3.5 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 deprecated `minimum_number_should_match` in BoolQueryBuilder After deprecating getters and setters and the query DSL parameter in 5.x, support for `minimum_number_should_match` can be removed entirely. Also consolidated comments with the ones on 5.x branch and added an entry to the migration docs.
2017-01-03 07:36:42 -05:00
* The deprecated `minimum_number_should_match` parameter in the `bool` query has
been removed, use `minimum_should_match` instead.
Fix parsing for `max_determinized_states` (#22749) There was a typo in the `ParseField` declaration. I know we want to port these parsers to `ObjectParser` eventually but I don't have the energy for that today and want to get this fixed. Closes #22722
2017-01-23 11:57:43 -05:00
* The `query_string` query now correctly parses the maximum number of
states allowed when
"https://en.wikipedia.org/wiki/Powerset_construction#Complexity[determinizing]"
a regex as `max_determinized_states` instead of the typo
`max_determined_states`.
Fix name of `enable_position_increments` (#22895) It was accidentally renamed `enabled_position_increment` in the cleanups for 5.0. This adds `enable_position_increment` as a deprecated alias so it will continue to work.
2017-02-03 15:02:19 -05:00
* The `query_string` query no longer accepts `enable_position_increment`, use
`enable_position_increments` instead.
Remove deprecated geo query parameters, and GeoPointDistanceRangeQuery This commit removes the following queries and parameters (which were deprecated in 5.0): * GeoPointDistanceRangeQuery * coerce, and ignore_malformed for GeoBoundingBoxQuery, GeoDistanceQuery, GeoPolygonQuery, and GeoDistanceSort
2017-01-30 18:20:43 -05:00
* For `geo_distance` queries, sorting, and aggregations the `sloppy_arc` option
has been removed from the `distance_type` parameter.
* The `geo_distance_range` query, which was deprecated in 5.0, has been removed.
* The `optimize_bbox` parameter has been removed from `geo_distance` queries.
* The `ignore_malformed` and `coerce` parameters have been removed from
`geo_bounding_box`, `geo_polygon`, and `geo_distance` queries.
[DOCS] Add sloppy_arc and factor removal to 6.0 migration docs
2017-02-03 10:49:01 -05:00
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.
ProfileResult and CollectorResult should print machine readable timing information (#22561) Currently both ProfileResult and CollectorResult print the time field in a human readable string format (e.g. "time": "55.20315000ms"). When trying to parse this back to a long value, for example to use in the planned high level java rest client, we can lose precision because of conversion and rounding issues. This change adds a new additional field (`time_in_nanos`) to the profile response to be able to get the original time value in nanoseconds back. The old `time` field is only printed when the `?`human=true` flag in the url is set. This follow the behaviour for all other stats-related apis. Also the format of the `time` field is slightly changed. Instead of always formatting the output as a 10-digit ms value, by using the `XContentBuilder#timeValueField()` method we now print the largest time unit present is used (e.g. "s", "ms", "micros").
2017-01-16 08:27:55 -05:00
==== Changes to the Profile API
* The `"time"` field showing human readable timing output has been replaced by the `"time_in_nanos"`
field which displays the elapsed time in nanoseconds. The `"time"` field can be turned on by adding
`"?human=true"` to the request url. It will display a rounded, human readable time value.
Document upcoming scoring changes. (#22806)
2017-01-30 05:08:49 -05:00
==== Scoring changes
Fixed bad asciidoc
2017-01-30 05:56:40 -05:00
===== Query normalization
Document upcoming scoring changes. (#22806)
2017-01-30 05:08:49 -05:00
Query normalization has been removed. This means that the TF-IDF similarity no
longer tries to make scores comparable across queries and that boosts are now
integrated into scores as simple multiplicative factors.
Other similarities are not affected as they did not normalize scores and
already integrated boosts into scores as multiplicative factors.
See https://issues.apache.org/jira/browse/LUCENE-7347[`LUCENE-7347`] for more
information.
Fixed bad asciidoc
2017-01-30 05:56:40 -05:00
===== Coordination factors
Document upcoming scoring changes. (#22806)
2017-01-30 05:08:49 -05:00
Coordination factors have been removed from the scoring formula. This means that
boolean queries no longer score based on the number of matching clauses.
Instead, they always return the sum of the scores of the matching clauses.
As a consequence, use of the TF-IDF similarity is now discouraged as this was
an important component of the quality of the scores that this similarity
produces. BM25 is recommended instead.
See https://issues.apache.org/jira/browse/LUCENE-7347[`LUCENE-7347`] for more
information.