2015-08-19 10:43:50 -04:00
|
|
|
[[breaking-changes-2.1]]
|
|
|
|
== Breaking changes in 2.1
|
|
|
|
|
|
|
|
This section discusses the changes that you need to be aware of when migrating
|
|
|
|
your application to Elasticsearch 2.1.
|
|
|
|
|
|
|
|
=== Search changes
|
|
|
|
|
|
|
|
==== `search_type=scan` deprecated
|
|
|
|
|
|
|
|
The `scan` search type has been deprecated. All benefits from this search
|
|
|
|
type can now be achieved by doing a scroll request that sorts documents in
|
|
|
|
`_doc` order, for instance:
|
|
|
|
|
|
|
|
[source,sh]
|
|
|
|
---------------
|
|
|
|
GET /my_index/_search?scroll=2m
|
|
|
|
{
|
|
|
|
"sort": [
|
|
|
|
"_doc"
|
|
|
|
]
|
|
|
|
}
|
|
|
|
---------------
|
|
|
|
|
|
|
|
Scroll requests sorted by `_doc` have been optimized to more efficiently resume
|
|
|
|
from where the previous request stopped, so this will have the same performance
|
2015-05-22 12:39:27 -04:00
|
|
|
characteristics as the former `scan` search type.
|
|
|
|
|
2015-08-28 14:16:45 -04:00
|
|
|
==== from + size limits
|
|
|
|
|
|
|
|
Elasticsearch will now return an error message if a query's `from` + `size` is
|
|
|
|
more than the `index.max_result_window` parameter. This parameter defaults to
|
|
|
|
10,000 which is safe for almost all clusters. Values higher than can consume
|
|
|
|
significant chunks of heap memory per search and per shard executing the
|
|
|
|
search. It's safest to leave this value as it is an use the scroll api for any
|
|
|
|
deep scrolling but this setting is dynamic so it can raised or lowered as
|
|
|
|
needed.
|
|
|
|
|
2015-05-22 12:39:27 -04:00
|
|
|
=== Update changes
|
|
|
|
|
|
|
|
==== Updates now `detect_noop` by default
|
|
|
|
|
|
|
|
We've switched the default value of the `detect_noop` option from `false` to
|
|
|
|
`true`. This means that Elasticsearch will ignore updates that don't change
|
|
|
|
source unless you explicitly set `"detect_noop": false`. `detect_noop` was
|
|
|
|
always computationally cheap compared to the expense of the update which can be
|
|
|
|
thought of as a delete operation followed by an index operation.
|
2015-08-28 00:07:56 -04:00
|
|
|
|
|
|
|
=== Removed features
|
|
|
|
|
|
|
|
==== `indices.fielddata.cache.expire`
|
|
|
|
|
|
|
|
The experimental feature `indices.fielddata.cache.expire` has been removed.
|
2015-09-02 15:45:56 -04:00
|
|
|
For indices that have this setting configured, this config will be ignored.
|
|
|
|
|
|
|
|
=== More Like This
|
|
|
|
|
|
|
|
The MoreLikeThisQueryBuilder#ignoreLike methods have been deprecating in favor
|
|
|
|
to using the unlike methods.
|
|
|
|
|
|
|
|
MoreLikeThisBuilder#addItem has been deprecated in favor to using
|
2015-09-09 12:39:23 -04:00
|
|
|
MoreLikeThisBuilder#addLikeItem.
|
|
|
|
|
|
|
|
=== Nested sorting
|
|
|
|
|
|
|
|
If sorting on field inside a nested object then the `nested_path` should be specified.
|
|
|
|
Before there was an attempt to resolve the nested path automatically, but that was sometimes incorrect.
|
2015-09-17 16:36:25 -04:00
|
|
|
To avoid confusion the `nested_path` should always be specified.
|
|
|
|
|
|
|
|
=== Deprecations
|
|
|
|
|
|
|
|
==== Optimize API
|
|
|
|
|
|
|
|
The Optimize API has been deprecated, all new optimize actions should use the new Force Merge API.
|