90 lines
2.7 KiB
Plaintext
90 lines
2.7 KiB
Plaintext
[[breaking-changes-3.0]]
|
|
== Breaking changes in 3.0
|
|
|
|
This section discusses the changes that you need to be aware of when migrating
|
|
your application to Elasticsearch 3.0.
|
|
|
|
=== Search changes
|
|
|
|
==== `search_type=count` removed
|
|
|
|
The `count` search type was deprecated since version 2.0.0 and is now removed.
|
|
In order to get the same benefits, you just need to set the value of the `size`
|
|
parameter to `0`.
|
|
|
|
For instance, the following request:
|
|
[source,sh]
|
|
---------------
|
|
GET /my_index/_search?search_type=count
|
|
{
|
|
"aggs": {
|
|
"my_terms": {
|
|
"terms": {
|
|
"field": "foo"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
---------------
|
|
|
|
can be replaced with:
|
|
[source,sh]
|
|
---------------
|
|
GET /my_index/_search
|
|
{
|
|
"size": 0,
|
|
"aggs": {
|
|
"my_terms": {
|
|
"terms": {
|
|
"field": "foo"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
---------------
|
|
|
|
==== `search_type=scan` removed
|
|
|
|
The `scan` search type was deprecated since version 2.1.0 and is now removed.
|
|
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
|
|
characteristics as the former `scan` search type.
|
|
|
|
=== Parent/Child changes
|
|
|
|
The `children` aggregation, parent child inner hits and `has_child` and `has_parent` queries will not work on indices
|
|
with `_parent` field mapping created before version `2.0.0`. The data of these indices need to be re-indexed into a new index.
|
|
|
|
The format of the join between parent and child documents have changed with the `2.0.0` release. The old
|
|
format can't read from version `3.0.0` and onwards. The new format allows for a much more efficient and
|
|
scalable join between parent and child documents and the join data structures are stored on on disk
|
|
data structures as opposed as before the join data structures were stored in the jvm heap space.
|
|
|
|
==== `score_type` has been removed
|
|
|
|
The `score_type` option has been removed from the `has_child` and `has_parent` queries in favour of the `score_mode` option
|
|
which does the exact same thing.
|
|
|
|
==== `sum` score mode removed
|
|
|
|
The `sum` score mode has been removed in favour of the `total` mode which doesn the same and is already available in
|
|
previous versions.
|
|
|
|
==== `max_children` option
|
|
|
|
When `max_children` was set to `0` on the `has_child` query then there was no upper limit on how many children documents
|
|
are allowed to match. This has changed and `0` now really means to zero child documents are allowed. If no upper limit
|
|
is needed then the `max_children` option shouldn't be defined at all on the `has_child` query. |