Setting client lib name properly by wrapping multiplxer creation

[atakavci]

Closes/Fixes #406

Current implementation for setting client lib info on connections is only working for single initial connection in the application context/runtime, which leaves the cases and setups given below out of scope;

• client reconnects
• pubsub subscription connections in RESP2 mode
• cluster setup

There are couple of ways to improve the situation with setting library info on connections but all have its downsides. Here some of them with their own drawbacks;

• using connections events
  • this doesnt provide a way to set subscription connections
  • need to manage event registration process for each and every connections explicitly, which is kind of unnecessary burden both in terms of performance and maintenance
• renaming/overriding internals with unnatural/unreliable ways
  • this is risky to play with internals of other library
  • this means introducing a sophisticated code/solution for a simple problem, which would make it
  • this is a potential maintenance issue due to relying on unexposed API/parts of StackExchange.Redis assembly.
• providing a high-level client initializer wrapping both database and multiplexer instances
  • this changes the initial point of contact of developer with the library API and change how the developer experiences
  • it brings maintenance work when the underlying API changes with IDatabase interface, this was handled in a zero-effort manner with help of extension methods previously

I choose to follow the third approach since it is clear, reliable and simplistic implementation compared to other two.
In this PR there are three major types introduced, two of them is exposed in public API;
IRedisDatabase : An interface to allow access to modules commands in addition to those in IDatabase
RedisClient : Provides creation+configuration of IRedisDatabase instances
DatabaseWrapper : Underlying wrapper class to compose IDatabase and modules commands into same type.

Existing implementation with extension methods will stay (at least until a major release) and we will keep these new types as experimental, until we make sure this approach brings more benefits, allow required modifications with underlying types and complies with up-coming changes with StackExchange.Redis.

[atakavci]

hey @slorello89 @uglide
let me know your thoughts on this.

[slorello89]

Couple minor nits, overall LGTM 👍 - will need to update docs to reflect it as well.

[slorello89]

This should be lifted out into an interface IRedisClient and should take an IConnectionMultiplexer in all the places.

[slorello89]

Link back to docs

[slorello89]

I'm assuming the idea here is that if we have a different opinion of how a command should be handled than StackExchange.Redis we can override it here without asking them to break?

[atakavci]

My main motivation here is more on keeping all commands accessible from same object/reference and keep the usage exact same compared to how it is provided with extension methods.

in the future, this might prove useful in the way you pointed out. However, I don't think we'd be inclined to interfere with how SE.Redis handles it.

[atakavci]

from same object/reference

from single object/reference

[mgravell]

I don't think we should do this in this way; in particular, wrapping IDatabase is hugely problematic. I strongly suggest that if needed, API changes are coordinated with SE.Redis. I have added further notes in #406

[mgravell]

reviewing again, it looks like the main thing here is to add the .BF() etc methods; we don't need to wrap anything for that - these can be implemented as extension methods

public static class RedisDatabaseExtensions
{
    public static BloomCommands BF(this IDatabase database) => new(database);
    public static CuckooCommands CF(this IDatabase database) => new(database);
    public static CmsCommands CMS(this IDatabase database) => new(database);
    // ...
    public static TimeSeriesCommands TS(this IDatabase database) => new(database);
}
...
var db = // existing SE.Redis API
var cf = db.CF();

There's also C# 14 "extension members", which would allow the exact same thing, but with properties - i.e.

var db = // existing SE.Redis API
var cf = db.CF;

This is quite appealing from a visual perspective, as it allows things like:

var db = // existing SE.Redis API
var result = db.CF.SomeMethod(args);

However, C# 14 demands .NET 10 SDK, which is not GA until (at a guess, based on history) November 2025.

[atakavci]

target here, as mentioned in description, to provide a reliable way to set client lib info. Best way to implement is to get some support or callback methods from SE.Redis for sure.

Since now we are to decide together and also have more resources to work on that, in case we can leverage SE.Redis directly, wrapping IDatabase is just a burden.

BTW .BF() and others already there as extension methods, this PR is just replicating them onto RedisClient to gain control on instantiation of IDatabase and embracing maintenance burden it brings.

In short, it would be very nice to see something like you mentioned here is provided and this PR gets redundant.