123 lines
3.4 KiB
Plaintext
123 lines
3.4 KiB
Plaintext
[[breaking_20_search_changes]]
|
|
=== Search changes
|
|
|
|
==== Partial fields
|
|
|
|
Partial fields have been removed in favor of <<search-request-source-filtering,source filtering>>.
|
|
|
|
==== `search_type=count` deprecated
|
|
|
|
The `count` search type has been deprecated. All benefits from this search
|
|
type can now be achieved by using the (default) `query_then_fetch` search type
|
|
and setting `size` to `0`.
|
|
|
|
==== The count api internally uses the search api
|
|
|
|
The count api is now a shortcut to the search api with `size` set to 0. As a
|
|
result, a total failure will result in an exception being returned rather
|
|
than a normal response with `count` set to `0` and shard failures.
|
|
|
|
==== All stored meta-fields returned by default
|
|
|
|
Previously, meta-fields like `_routing`, `_timestamp`, etc would only be
|
|
included in the search results if specifically requested with the `fields`
|
|
parameter. Now, all meta-fields which have stored values will be returned by
|
|
default. Additionally, they are now returned at the top level (along with
|
|
`_index`, `_type`, and `_id`) instead of in the `fields` element.
|
|
|
|
For instance, the following request:
|
|
|
|
[source,sh]
|
|
---------------
|
|
GET /my_index/_search?fields=foo
|
|
---------------
|
|
|
|
might return:
|
|
|
|
[source,js]
|
|
---------------
|
|
{
|
|
[...]
|
|
"hits": {
|
|
"total": 1,
|
|
"max_score": 1,
|
|
"hits": [
|
|
{
|
|
"_index": "my_index",
|
|
"_type": "my_type",
|
|
"_id": "1",
|
|
"_score": 1,
|
|
"_timestamp": 10000000, <1>
|
|
"fields": {
|
|
"foo" : [ "bar" ]
|
|
}
|
|
}
|
|
]
|
|
}
|
|
}
|
|
---------------
|
|
<1> The `_timestamp` is returned by default, and at the top level.
|
|
|
|
|
|
==== Script fields
|
|
|
|
Script fields in 1.x were only returned as a single value. Even if the return
|
|
value of a script was a list, it would be returned as an array containing an
|
|
array:
|
|
|
|
[source,js]
|
|
---------------
|
|
"fields": {
|
|
"my_field": [
|
|
[
|
|
"v1",
|
|
"v2"
|
|
]
|
|
]
|
|
}
|
|
---------------
|
|
|
|
In elasticsearch 2.0, scripts that return a list of values are treated as
|
|
multivalued fields. The same example would return the following response, with
|
|
values in a single array.
|
|
|
|
[source,js]
|
|
---------------
|
|
"fields": {
|
|
"my_field": [
|
|
"v1",
|
|
"v2"
|
|
]
|
|
}
|
|
---------------
|
|
|
|
==== Timezone for date field
|
|
|
|
Specifying the `time_zone` parameter in queries or aggregations on fields of
|
|
type `date` must now be either an ISO 8601 UTC offset, or a timezone id. For
|
|
example, the value `+1:00` must now be written as `+01:00`.
|
|
|
|
==== Only highlight queried fields
|
|
|
|
The default value for the `require_field_match` option has changed from
|
|
`false` to `true`, meaning that the highlighters will, by default, only take
|
|
the fields that were queried into account.
|
|
|
|
This means that, when querying the `_all` field, trying to highlight on any
|
|
field other than `_all` will produce no highlighted snippets. Querying the
|
|
same fields that need to be highlighted is the cleaner solution to get
|
|
highlighted snippets back. Otherwise `require_field_match` option can be set
|
|
to `false` to ignore field names completely when highlighting.
|
|
|
|
The postings highlighter doesn't support the `require_field_match` option
|
|
anymore, it will only highlight fields that were queried.
|
|
|
|
==== Postings highlighter doesn't support `match_phrase_prefix`
|
|
|
|
The `match` query with type set to `phrase_prefix` (or the
|
|
`match_phrase_prefix` query) is not supported by the postings highlighter. No
|
|
highlighted snippets will be returned.
|
|
|
|
|
|
|