SphinxConnector.NET 6.1 has been released

By Dennis

We're pleased to announce that SphinxConnector.NET 6.1 is now available via NuGet! You can also download a build from our site, but that only contains a version for .NET Framework 4.6.2. and higher.

This release adds support for authenticated connections to Sphinx and Manticore Search. Please note that with Sphinx, only SHA1 hashed passwords (mysql_native_auth) are supported in this release.

We’ve also added the ability to configure the logger provider and set the license key during the FulltextStore initialization call:

var fulltextStore = new FulltextStore().Initialize(c => c.SetLicense("Your license key").
                                                          SetLoggerProvider(new ConsoleLoggerProvider()));

This should make for some nicer setup during container registration of the fluent API classes.

Additionally, you can now set the license key via an environment variable called SPHINXCONNECTOR_LICENSE_KEY for scenarios where you the retrieve the key from a vault of some kind, e.g. for containerized setups.

For a full list of changes, please refer to the version history.

SphinxConnector.NET 5.4 has been released

By Dennis

We're pleased to announce that SphinxConnector.NET 5.4 is now available via NuGet! You can also download a build from our site, but that only contains a version for .NET Framework 4.6.1. and higher.

This release adds .NET 8.0 as a new build target and provides basic support for tracing via OpenTelemetry. In the first iteration tracing connection lifetime and executed statements is supported.

For a full list of changes, please refer to the version history.

SphinxConnector.NET 5.2 has been released

By Dennis

We're pleased to announce that SphinxConnector.NET 5.2 is now available via NuGet! You can also download a build from our site, but that only contains a version for .NET Framework 4.6.1. and higher.

This release adds .NET 7.0 as a new build target. We've removed builds for .NET 5 since it has reached end of support in May. We’ve fixed a bug that was preventing the usage of IndexOf in conjunction with a dictionary that represents a JSON attribute e.g. an expression like this:

((List<string>)x.Properties["Categories"]).IndexOf("Fiction") > -1

For a full list of changes, please refer to the version history.

SphinxConnector.NET 5.1 has been released

By Dennis

We're pleased to announce that SphinxConnector.NET 5.1 is now available via NuGet! You can also download a build from our site, but that only contains a version for .NET Framework 4.6.1. and higher.

This release adds a build for .NET 6.0, while .NET Core 2.1 has been removed as a target as it has gone out of support. We’ve added support for Manticore’s new LEVENSHTEIN() function and the DateOnly type introduced in .NET 6.

For a full list of changes, please refer to the version history.

SphinxConnector.NET 5.0 has been released

By Dennis

We're pleased to announce that SphinxConnector.NET 5.0 is now available via NuGet! You can also download a build from our site, but that only contains a version for .NET Framework 4.6.1. and higher.

With this release we’re saying good bye to Common.Logging, which has been replaced with our own logging abstraction. We’re providing separate NuGet packages for the most commonly used logging frameworks, namely:

Also included in SphinxConnector.NET is a simple console logging provider that can be used during development.

The second change in dependencies is the switch from JSON.NET to System.Text.Json as the default json handler. If for some reason you need to stay on JSON.NET, you can easily do so by implementing your own JsonObjectSerializer.

SphinxConnector.NET now includes builds for .NET Core 3.1 and .NET 5.0, where we’ve added implementations for new async methods to SphinxQLDataReader that were introduced with .NET Core 3.1. These builds also contain fluent API support for async enumerables via IFulltextQuery.ToAsyncEnumerable().

The biggest new feature is the introduction of prepared (sometimes also called ‘compiled’) queries to the fluent API.
The idea behind prepared queries is to create a query template that is parsed once and then reused on the following executions thus alleviating the overhead caused by parsing the expression tree and generating the SphinxQL statement. This can lead to significant reductions in allocations and time spend on parsing the expression tree of a query, especially in high load scenarios, while at the same time giving you all the advantages of a strongly typed query API. More about prepared queries can be found in the documentation.

For a full list of changes, please refer to the version history.