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
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…
- Support for indexed scripts
- Support for the geohash cell filter
- New highlighting features
- New connection setting to enable/disable HTTP pipelining on the client. #1032
See the 1.3 release notes for the complete list of changes.
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.
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.