NEST 1.4 Released
The .NET team within Elasticsearch is happy to announce that NEST and Elasticsearch.NET 1.4 are now available on nuget.org!
The big theme for this release was
Elasticsearch 1.4 parity.
After we released
NEST 1.3, we went through all the PR’s that made it into
Elasticsearch 1.4 and created tickets for them in our own GitHib issues. Within 2 weeks, all of them were closed!
This means that you can now use the new
scripted metric aggregations, or call the
Get Index API. Check out the 1.4 release notes for the full list.
Rather than releasing before Christmas, we focused on closing as many of the lingering open tickets and stability fixes as possible.
RequestTimeout()now dictates how long ALL calls can take collectively rather than controlling how long each individual call may take. This means that a request timeout of
60 secondswon’t turn into
MaxRetries()is set to
- @aochsner discovered that when passing a request timeout override for a single request it was ignored.
- Thrift connection did not respect connect timeout.
- Thrift connection did not accept new nodes from the
- Some code paths did not keep track of exceptions to be reported back properly.
- When not using connection pooling we did not respect
We also heard from many of our users that our default connect timeout of
200ms was a little too stringent on cloud platforms. Our default timeout is now
2s when using
Better shield support
NEST 1.3 fully supports all the moving parts of Shield, but we found a bug in our
SniffingConnectionPool that would reintroduce newly found nodes as
http and not
https. If you are planning to use shield and
SniffingConnectionPool, upgrading to
NEST 1.4 is highly recommended.
We also added a greater default connect timeout when using
SSL, which is now set to
2s. We found that connecting locally over
SSL is typically fast enough, but when using remote nodes you need some more leeway built in.
Configuring ids in code
An old open issue, long ignored, has finally made it in!
NEST by default infers
id‘s on objects when they are not passed explicitly by looking at the
Id property of your
Previously the only way to override this behavior was through the
This change introduced an alternative way to configure id properties, via code:
var settings = new ConnectionSettings() .MapIdPropertyFor(o => o.AlternateId);
Observe on backups and restores
ReIndex(), that coordinates several long running/sequential calls and exposes them as an
IObservable, we now offer a similar experience for backup and restore:
var interval = TimeSpan.FromMilliseconds(100); var restoreObservable = this.Client.RestoreObservable(interval, r => r .Repository(_repositoryName) .Snapshot(_snapshotName) .RenamePattern(d + "_(.+)") .RenameReplacement(d + "_restored_$1") .Index(_indexName) .IgnoreUnavailable(true));
In this example we will return an
IObservable that you can subscribe allowing you to monitor restore progress and be notified when it completes (or fails).
Many many thanks to Robert Lyson who volunteered to implement this new feature.
.NET 4.5 builds in our NuGet package.
We included specific
.NET 4.5 builds of our DLLs in our NuGet package so that you can now use
Elasticsearch on .NET Core applications that target the desktop CLR (
KRE-CLR-*). Support for the Core CLR (
KRE-CoreCLR-*) is high on our wishlist but since it might mean some breaking changes it won’t be available until we release
Every release blog post we touch on how much we appreciate your contributions, but we really really do! We are pleasantly surprised at the number of you who are on the bleeding edge builds and help us spot errors before they are even released. Andrey Mironoff deserves a special mention here for helping us catch an edge case aggregation parser bug in our bleeding edge builds by providing one of the best reproduce code we’ve ever seen, allowing us to fix the bug within hours.
As always many of our features and bug fixes have been provided by the community, thank you!
If you are developing a .NET application with NEST and you need a fix that has not been released on NuGet yet, remember you can always get our bleeding edge builds from MyGet. Keep in mind, these builds have been unit tested but have not gone through the rigorous integration testing that we do for our NuGet releases against every Elasticsearch
We are going to focus on our
2.0 branch making it the default branch on GitHub as well.
develop will go into maintenance mode, keeping track with Elasticsearch updates and
Our current status-quo means we have 5 different unit/integration tests projects, we have been spiking a unique approach to unify all our testing and documentation needs using Roslyn with something we’ve dubbed literate testing. Much of our efforts in 2.0 will be to re-architect our testing infrastructure.
aspnet50core support will dictate much of our rewrite. The most intrusive issue being that
WebRequest is longer available, so we will move to
HttpClient as our default
We have no plans to drop
.NET 4.0 support though!
Another huge part that we hope to tackle in 2.0 is to formalize Elasticsearch’s request and responses and hopefully be able to generate our domain and JSON serialization for optimal performance.