Tech Topics

Nest and Elasticsearch.Net 1.3

By
Greg Marzouka

Last week, we released NEST and Elasticsearch.NET 1.3, while not one of our most action-packed releases, during its postmortem we realized there were quite a few important features and fixes that warranted a blog post!

New Security Features:

You may have heard that Elasticsearch is coming out with a new security product, Shield. Shield offers a rich set of features for securing your Elasticsearch cluster, and we took the initiative to make sure NEST and Elasticsearch.NET will have full support for Shield when it’s officially released.

Improved Basic Authentication API:

Prior to 1.3, basic authentication credentials could only be specified on the URI like so:

var uri = new Uri("http://username:password@localhost:9200");
var settings = new ConnectionSettings(uri);

This isn’t the best way to manage credentials in your application, and more importantly it doesn’t allow you to specify different credentials per request.

Now you can specify basic authentication credentials for all requests at the global ConnectionSettings level as follows:

var uri = new Uri("http://localhost:9200");
var settings = new ConnectionSettings(uri);
    .SetBasicAuthentication("user", "password");

Or per request, overriding any credentials set at the global level:

var response = client.Search<MyClass>(s => s
    .MatchAll()
    .RequestConfiguration(rc => rc
        .BasicAuthentication("anotheruser", "password")
    )
);

Remember: The client is thread-safe, so you can use a single client, in which case, passing a per request configuration is the only way to pass state local to the request. Instantiating a client each time is also supported. In this case each client instance could hold a different ConnectionSettings object with their own set of basic authorization credentials. Do note that if you new a client each time (or your IoC does), they all should use the same IConnectionPool instance.

401 (Unauthorized Request) Handling:

Now that an HTTP 401 is a valid response from Elasticsearch, we had to make some modifications to our connection pooling retry logic in order to fail as quickly as possible on 401 responses, and not retry the request on other nodes.

New Property Name Mapping API:

Prior to 1.3, expressions (e.g p => p.Name) could only be controlled using the ElasticProperty attribute, or the shotgun ConnectionSettings.SetDefaultPropertyNameInferrer() which happens too late in the pipeline to know which property on what type it actually is.

Therefore, we introduced a third approach to override what a strongly typed expression resolves to:

settings.MapPropertiesFor<MyClass>(props => props
    .Rename(p => p.Foo, "bar")
);

This allows you to refer to the property using the expression p => p.Foo in any of the API calls, but resolving the property name to bar before being sent to Elasticsearch.

Additionally, before 1.3, the only way to exclude properties from being mapped was to use [ElasticProperty(OptOut=true)] or Json.NET’s JsonIgnore attribute on the property. Now with this new API, you can also ignore properties in code:

settings.MapPropertiesFor<MyClass>(props => props
    .Rename(p => p.Foo, "bar")
    .Ignore(p => p.Bar)
);

Other New Features:

We received an influx of pull requests from our community, so a special thank you to everyone who contributed to this release!

Just some of the new features added in 1.3…

See the 1.3 release notes for the complete list of changes.

what’s next?

Elasticsearch 1.4 Features

Elasticsearch 1.4 brings a ton of new APIs and aggregations. We plan on mapping all of them in our 1.4 release of NEST and Elasticsearch.NET. For a list of all the features that are currently planned, just filter by the 1.4 label on our GitHub issues page. This list is constantly growing, so please feel free to add to it, or let us know if we’re missing anything.

ASP.NET vNext

It’s an exciting time to be a .NET developer! If you’ve been keeping up with the latest news, then you know that .NET is now open source and Microsoft is cooking up some awesomeness with ASP.NET 5 (vNext), an exciting alternative, leaner stack to develop .NET applications on. Starting with NEST 1.4 we will include a proper .NET 4.5 build that works on KRE-CLR-*.1.0.0-beta1 and up. We are also exploring adding support for the new cross platform core CLR (KRE-CoreCLR-*) in this branch, though support for this is not a blocker for a 1.4 release of NEST.

That’s all from the .NET corner at Elasticsearch. As always, please don’t hesitate to submit your questions/suggestions/issues to either GitHub or StackOverflow.