[[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.