Search changes

Partial fields have been removed in favor of source filtering.

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

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:

GET /my_index/_search?fields=foo

might return:

{
   [...]
   "hits": {
      "total": 1,
      "max_score": 1,
      "hits": [
         {
            "_index":     "my_index",
            "_type":      "my_type",
            "_id":        "1",
            "_score":     1,
            "_timestamp": 10000000, 
            "fields": {
              "foo" : [ "bar" ]
            }
         }
      ]
   }
}

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:

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

"fields": {
  "my_field": [
    "v1",
    "v2"
  ]
}

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.

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.

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.