This lists all the binary breaking changes in Elasticsearch.Net from 5.x (last commit in 5.x at time of 6.0.0 GA release) to 6.x (6.0.0 GA release). The intention in providing such a large list is to allow you to quickly and easily search the changes between the two major versions, to understand what has been removed and equally importantly, what has been added.

Requestsedit

Request parametersedit

Our code that takes the Elasticsearch REST API specifications and generates the low-level client had been mostly untouched since 1.x. Since 1.x, request parameters were fluent e.g.

client.Search<dynamic>(r => r.Parameter())`

This was done back in the day to facilitate the high-level client but was never truly needed. Now, the low-level client is using

client.Search<DynamicResponse>(new SearchRequestParameters { Parameter = .. })`.

This change affects the following:

Responsesedit

In previous version any client.Operation<T>(..) accepted string byte[], dynamic, Stream, VoidResponse, or any object to deserialize the response into as T and returned an ElasticsearchResponse<T>.

We are now stricter and constrained T to IElasticsearchResponse and always return T directly.

To help ease the common use cases we ship with an BytesResponse, StringResponse, DynamicResponse, VoidResponse and ElasticsearchResponse<T> where T can again be any object to deserialize the response into.

In previous versions the low level client was in charge of reading deserialized exceptions from Elasticsearch and short circuited if a bad HTTP status code was returned to do so. Omitting the deserializer all together. This worked in Elasticsearch 2.x however starting with 5.x several API’s can also return something other than a serialized exception on non valid HTTP status codes. To combat this the client in certain cases for some API’s needs to do a double read of the API. By shifting this responsibility from the client to the callee we no longer need to bake in any kind of special casing.

The response stream is now always fed directly into the configured serializer, not just for known OK HTTP status codes. Unless you explicitly call DisableDirectStreaming or set DebugMode() in which case the request and response bytes are available on response.DebugInformation.

The builtin BytesResponse and StringResponse both have a TryGetServerError to still easily get a typed view on the exception that happened on the server.

For the high level client NEST nothing changes .ServerError is still available on all its responses. This change means NEST is in charge of deserializing the server error and not the low level client Elasticsearch.Net though.

Lastly we removed support for return the raw response stream, this was a dangerous feature because the onous on disposing that stream lied with the user. If you need to access the response stream directly inject a custom IElasticsearchSerializer.

Error handlingedit

Connectionsedit

Serializationedit

ElasticLowLevelClientedit

Although the list of changes here is large, the majority of them are related to the request parameters changes from using a fluent method to define parameters, to passing an instance directly