Elasticsearch .NET Client release notes
Review the changes, fixes, and more in each version of Elasticsearch .NET Client.
To check for security updates, go to Security announcements for the Elastic stack.
- 1. Request Method/API Changes
- 2. Improved Fluent API
- 3. Improved Descriptor Design
- 4. Request Path Parameter Properties
- 5. Field Name Inference
- 6. Uniform Date/Time/Duration Types
- 7. Improved Container Design
- 8. Sorting
- 9. Safer Object Creation
- 10. Serialization
Synchronous request APIs are no longer marked as obsolete
. We received some feedback about this deprecation and decided to revert it.
It is now possible to specify separate type arguments for requests/responses when executing request methods:
var response = await client.SearchAsync<Person, JsonObject>(x => x
.Query(x => x.Term(x => x.Field(x => x.FirstName).Value("Florian")))
);
var documents = response.Documents;
IReadOnlyCollection<JsonObject>
The regular APIs with merged type arguments are still available.
The enhanced fluent API generation is likely the most notable change in the 9.0 client.
This section describes the main syntax constructs generated based on the type of the property in the corresponding object.
Note: This syntax already existed in 8.x.
new SearchRequestDescriptor<Person>()
.Query(q => q
.Bool(b => b
.Must(new Query())
.Must(new Query(), new Query())
.Must(m => m.MatchAll())
.Must(m => m.MatchAll(), m => m.MatchNone())
)
);
- Scalar: Single element.
- Scalar: Multiple elements (params).
- Fluent: Single element.
- Fluent: Multiple elements (params).
The 9.0 client introduces full fluent API support for dictionary types.
new SearchRequestDescriptor<Person>()
.Aggregations(new Dictionary<string, Aggregation>())
.Aggregations(aggs => aggs
.Add("key", new MaxAggregation())
.Add("key", x => x.Max())
)
.AddAggregation("key", new MaxAggregation())
.AddAggregation("key", x => x.Max());
- Scalar.
- Fluent: Nested.
- Scalar: Key + Value.
- Fluent: Key + Value.
- Scalar.
- Fluent.
The Add{Element}
methods have different semantics compared to the standard setter methods.
Standard fluent setters set or replace a value.
In contrast, the new additive methods append new elements to the dictionary.
For dictionaries where the value type does not contain required properties that must be initialized, another syntax is generated that allows easy addition of new entries by just specifying the key:
// Dictionary<Name, Alias>()
new CreateIndexRequestDescriptor("index")
// ... all previous overloads ...
.Aliases(aliases => aliases
.Add("key")
)
.Aliases("key")
.Aliases("first", "second")
- Fluent: Nested.
- Key only.
- Key only: Single element.
- Key only: Multiple elements (params).
If the value type in the dictionary is a collection, additional params
overloads are generated:
// Dictionary<Field, ICollection<CompletionContext>>
new CompletionSuggesterDescriptor<Person>()
// ... all previous overloads ...
.AddContext("key",
new CompletionContext{ Context = new Context("first") },
new CompletionContext{ Context = new Context("second") }
)
.AddContext("key",
x => x.Context(x => x.Category("first")),
x => x.Context(x => x.Category("second"))
);
Elasticsearch often uses ICollection<KeyValuePair<K, V>>
types for ordered dictionaries.
The 9.0 client abstracts this implementation detail by providing a fluent API that can be used exactly like the one for IDictionary<K, V>
types:
new PutMappingRequestDescriptor<Person>("index")
.DynamicTemplates(new List<KeyValuePair<string, DynamicTemplate>>())
.DynamicTemplates(x => x
.Add("key", new DynamicTemplate())
.Add("key", x => x.Mapping(new TextProperty()))
)
.AddDynamicTemplate("key", new DynamicTemplate())
.AddDynamicTemplate("key", x => x.Runtime(x => x.Format("123")));
- Scalar.
- Fluent: Nested.
- Scalar: Key + Value.
- Fluent: Key + Value.
- Scalar: Key + Value.
- Fluent: Key + Value.
Fluent syntax is now as well available for all auto-generated union- and variant-types.
// TermsQueryField : Union<ICollection<FieldValue>, TermsLookup>
new TermsQueryDescriptor()
.Terms(x => x.Value("a", "b", "c"))
.Terms(x => x.Lookup(x => x.Index("index").Id("id")));
ICollection<FieldValue>
TermsLookup
The 9.0 release features a completely overhauled descriptor design.
Descriptors now wrap the object representation. This brings several internal quality-of-life improvements as well as noticeable benefits to end-users.
Use the wrap constructor to create a new descriptor for an existing object:
var request = new SearchRequest();
// Wrap.
var descriptor = new SearchRequestDescriptor(request);
All fluent methods of the descriptor will mutate the existing request
passed to the wrap constructor.
Descriptors are now implemented as struct
instead of class
, reducing allocation overhead as much as possible.
Descriptor values can now be inspected by unwrapping the object using an implicit conversion operator:
var descriptor = new SearchRequestDescriptor();
// Unwrap.
SearchRequest request = descriptor;
Unwrapping does not allocate or copy.
In 8.x, execution of (most but not all) lambda actions passed to descriptors was deferred until the actual request was made. It was never clear to the user when, and how often an action would be executed.
In 9.0, descriptor actions are always executed immediately. This ensures no unforeseen side effects occur if the user-provided lambda action mutates external state (it is still recommended to exclusively use pure/invariant actions). Consequently, the effects of all changes performed by a descriptor method are immediately applied to the wrapped object.
In 8.x, request path parameters like Index
, Id
, etc. could only be set by calling the corresponding constructor of the request. Afterwards, there was no way to read or change the current value.
In the 9.0 client, all request path parameters are exposed as get/set
properties, allowing for easy access:
// 8.x and 9.0
var request = new SearchRequest(Indices.All);
// 9.0
var request = new SearchRequest { Indices = Indices.All };
var indices = request.Indices;
request.Indices = "my_index";
The Field
type and especially its implicit conversion operations allowed for null
return values. This led to a poor developer experience, as the null-forgiveness operator (!
) had to be used frequently without good reason.
This is no longer required in 9.0:
// 8.x
Field field = "field"!;
// 9.0
Field field = "field";
The encoding of date, time and duration values in Elasticsearch often varies depending on the context. In addition to string representations in ISO 8601 and RFC 3339 format (always UTC), also Unix timestamps (in seconds, milliseconds, nanoseconds) or simply seconds, milliseconds, nanoseconds are frequently used.
In 8.x, some date/time values are already mapped as DateTimeOffset
, but the various non-ISO/RFC representations were not.
9.0 now represents all date/time values uniformly as DateTimeOffset
and also uses the native TimeSpan
type for all durations.
There are some places where the Elasticsearch custom date/time/duration types are continued to be used. This is always the case when the type has special semantics and/or offers functionality that goes beyond that of the native date/time/duration types (e.g. Duration
, DateMath
).
In 8.x, container types like Query
or Aggregation
had to be initialized using static factory methods.
// 8.x
var agg = Aggregation.Max(new MaxAggregation { Field = "my_field" });
This made it mandatory to assign the created container to a temporary variable if additional properties of the container (not the contained variant) needed to be set:
// 8.x
var agg = Aggregation.Max(new MaxAggregation { Field = "my_field" });
agg.Aggregations ??= new Dictionary<string, Aggregation>();
agg.Aggregations.Add("my_sub_agg", Aggregation.Terms(new TermsAggregation()));
Additionally, it was not possible to inspect the contained variant.
In 9.0, each possible container variant is represented as a regular property of the container. This allows for determining and inspecting the contained variant and initializing container properties in one go when using an object initializer:
// 9.0
var agg = new Aggregation
{
Max = new MaxAggregation { Field = "my_field" },
Aggregations = new Dictionary<string, Aggregation>
{
{ "my_sub_agg", new Aggregation{ Terms = new TermsAggregation() } }
}
};
Previously required methods like e.g. TryGet<TVariant>(out)
have been removed.
The new recommended way of inspecting container types is to use simple pattern matching:
var query = new Query();
if (query.Nested is { } nested)
{
// We have a nested query.
}
A container can still only contain a single variant. Setting multiple variants at once is invalid.
Consecutive assignments of variant properties (e.g., first setting Max
, then Min
) will cause the previous variant to be replaced.
Applying a sort order to a search request using the fluent API is now more convenient:
var search = new SearchRequestDescriptor<Person>()
.Sort(
x => x.Score(),
x => x.Score(x => x.Order(SortOrder.Desc)),
x => x.Field(x => x.FirstName),
x => x.Field(x => x.Age, x => x.Order(SortOrder.Desc)),
x => x.Field(x => x.Age, SortOrder.Desc)
// 7.x syntax
x => x.Field(x => x.Field(x => x.FirstName).Order(SortOrder.Desc))
);
The improvements are even more evident when specifying a sort order for aggregations:
new SearchRequestDescriptor<Person>()
.Aggregations(aggs => aggs
.Add("my_terms", agg => agg
.Terms(terms => terms
// 8.x syntax.
.Order(new List<KeyValuePair<Field, SortOrder>>
{
new KeyValuePair<Field, SortOrder>("_key", SortOrder.Desc)
})
// 9.0 fluent syntax.
.Order(x => x
.Add(x => x.Age, SortOrder.Asc)
.Add("_key", SortOrder.Desc)
)
// 9.0 fluent add syntax (valid for all dictionary-like values).
.AddOrder("_key", SortOrder.Desc)
)
)
);
In version 9.0, users are better guided to correctly initialize objects and thus prevent invalid requests.
For this purpose, at least one constructor is now created that enforces the initialization of all required properties. Existing parameterless constructors or constructor variants that allow the creation of incomplete objects are preserved for backwards compatibility reasons, but are marked as obsolete.
For NET7+ TFMs, required properties are marked with the required
keyword, and a non-deprecated parameterless constructor is unconditionally generated.
Please note that the use of descriptors still provides the chance to create incomplete objects/requests, as descriptors do not enforce the initialization of all required properties for usability reasons.
Serialization in version 9.0 has been completely overhauled, with a primary focus on robustness and performance. Additionally, initial milestones have been set for future support of native AOT.
In 9.0, round-trip serialization is now supported for all types (limited to all JSON serializable types).
var request = new SearchRequest{ /* ... */ };
var json = client.ElasticsearchClientSettings.RequestResponseSerializer.SerializeToString(
request,
SerializationFormatting.Indented
);
var searchRequestBody = client.ElasticsearchClientSettings.RequestResponseSerializer.Deserialize<SearchRequest>(json)!;
Note that only the body is serialized for request types. Path- and query properties must be handled manually.
It is important to use the RequestResponseSerializer
when (de-)serializing client internal types. Direct use of JsonSerializer
will not work.