Breaking changes in Elasticsearch 1.0

[grantr]

Elasticsearch 1.0 breaks a bunch of stuff. Current list of changes is at http://www.elasticsearch.org/guide/en/elasticsearch/reference/master/breaking-changes.html.

As far as I can tell, the following will require changes to Elastomer or github.com:

New stats url format

The stats urls now rely on url path instead of parameters for filtering. http://www.elasticsearch.org/guide/en/elasticsearch/reference/master/_stats_and_info_apis.html

New admin api url formats

Some of the admin url formats have changed. http://www.elasticsearch.org/guide/en/elasticsearch/reference/master/_indices_apis.html

Cannot index document with type wrapper

I don't think we ever did this, but if we did it's not allowed by default anymore. http://www.elasticsearch.org/guide/en/elasticsearch/reference/master/_index_request.html

All search apis take a :query element in the body

Yay! This was the source of much ambiguity (and a few Elastomer bugs). http://www.elasticsearch.org/guide/en/elasticsearch/reference/master/_search_requests.html

Top level :filter element renamed to :post_filter

We used to use this heavily in dotcom, less so now. http://www.elasticsearch.org/guide/en/elasticsearch/reference/master/_search_requests.html

New multifield syntax

I believe we use these in a few places in dotcom. Minor syntax change. http://www.elasticsearch.org/guide/en/elasticsearch/reference/master/_multi_fields.html

No english stopwords in standard and pattern analyzers

If we want to continue using stopwords, we'll have to add a stopword filter manually. http://www.elasticsearch.org/guide/en/elasticsearch/reference/master/_stopwords.html

New fuzzy query parameters

I think we use fuzzy queries for autocomplete queries. http://www.elasticsearch.org/guide/en/elasticsearch/reference/master/_parameters.html

No more ok elements in responses

I think haystack relies on this, and maybe some tests and other things? http://www.elasticsearch.org/guide/en/elasticsearch/reference/master/_return_values.html

That's what stood out to me. Everyone working with ES should take a look and see if they'll have to change anything.

/cc @github/search

[grantr]

Nested settings instead of flattened keys

Settings responses now return nested hashes instead of flattened keys. Settings requests support both formats. The old behavior can be enabled with the ?flat_settings query string parameter.
http://www.elasticsearch.org/guide/en/elasticsearch/reference/master/_return_values.html

This broke Elastomer tests and could break settings management code in apps and puppet.

[grantr]

The field query has been removed

ES doc recommends using query_string instead, but match might be a better choice.
http://www.elasticsearch.org/guide/en/elasticsearch/reference/1.x/_deprecations.html

get_mapping nests mappings under a "mappings" element

Code expecting the {"index-name":{"type-name":{ #mapping }}} response format will need to be updated to expect {"index-name":{"mappings":{"type-name":{ #mapping }}} format.

[grantr]

/ref https://github.com/github/search/issues/12

[grantr]

response['ok'] and response['created'] are not equivalent

In the 1.0 index api response, the ok attribute has been removed and a created attribute has been added. The behavior of the created element is different. The created attribute is only true when the document is new. If the document already existed, then created will be false even though the request succeeded.

Don't replace ok with created in conditionals expecting created to always be true, because it won't be.

[grantr]

field values in restricted fields queries are always arrays

In the 1.0 search response, when using fields=updated_at in the query string, the field values are now always arrays, regardless of the multiplicity of the source.

Pre-1.0:

  {
      "_index" : "pull-requests",
      "_type" : "pull_request",
      "_id" : "21614",
      "_score" : 1.0,
      "fields" : {
        "created_at" : "2012-03-02T22:48:56-08:00"
      }
    }

Post-1.0:

{
      "_index" : "haystack-development",
      "_type" : "needle",
      "_id" : "2aRWKAQlpbXSe1gIDZMRdg",
      "_score" : 1.0,
      "fields" : {
        "created_at" : [ "2014-05-02T00:18:41Z" ]
      }
    }

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/_return_values.html

[grantr]

The fields parameter can no longer return object fields

In 1.0, an object mapping cannot be used in the fields parameter. For example, given a mapping with the following fields:

comments.author_id
comments.created_at
comments.body

In 0.90 it was possible to use fields=comments to return all comments fields. In 1.0, this will raise an error explaining that comments isn't a leaf field:

{
  "error" : "SearchPhaseExecutionException[Failed to execute phase [query_fetch],
 all shards failed;
 shardFailures {[vyOMeRAISo21L_a48a0svw][issues][0]: 
ElasticsearchIllegalArgumentException[field [comments] isn't a leaf field]}]",
  "status" : 400
}

It is now necessary to use source filtering via the _source parameter to retrieve entire objects.

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/_return_values.html
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-source-filtering.html

[grantr]

Routing is now required for single-shard APIs

Prior to 1.0, some APIs that only hit a single shard (like get) did not require a routing parameter even if the mapping specifies that routing is required. In 1.x those APIs fail if a routing parameter is not supplied.

elastic/elasticsearch#4523