![]() It would be sucky if there was a mix of external extensions targeting one, the other, or both. ![]() Tl,dr: currently, there are two packages for the client library - strong named and not strong named. I'm not going to opine on strong naming here - the discussion is not very interesting and has been done to death. This also makes "strong naming" rear it's ugly head. NET), and b: it would be good to gauge interest and uptake before spending any time doing this. I'd like to add a second API specifically intended for extensions like this (more direct, less allocations, etc), but a: ideally I'd want to ensure that I can subsequently tie it cleanly into the "pipelines" concept (which is currently just a corefxlab dream, without a known ETA for "real". But being realistic, it is probably fine for 95% of use-cases, so: let's get that shipped and iterate from there. ![]() The slight wrinkle here is that it is still using the Execute API as a general-purpose API it is very convenient and flexible, but slightly more expensive than it absolutely needs to be. Return SomeJsonSerializer.Deserialize(ms) To expose raw json functionality, or could choose to add serialization / deserialization into the mix too: public static T JsonGet(this IDatabase db, RedisKey key,īyte bytes = (byte)db.Execute("JSON.GET", Return (RedisValue)db.Execute("JSON.GET", String path = ".", CommandFlags flags = CommandFlags.None) My hope here is that or well-known but non-trivial modules, "someone" (maybe me, maybe the wider community) will be able to write helper methods as C# extension methods against the client library, and package them as module-specific NuGet packages for example, a package could add: public static RedisValue JsonGet(this IDatabase db, RedisKey key, What about more graceful handling for well-known modules? The key from all of this is that it should be easy to quickly hook into any modules that you write or want to consume. It also recognises parameters typed as RedisKey and uses them for routing / sharding purposes as necessary. The parameters are simply a string command name, and a params object of everything else - with appropriate handling of the types you're likely to use with redis commands ( string, int, double, etc). The return value of these methods is the flexible RedisResult type that the Lua API already exposes, which handles all the expected scenarios of primitives, arrays, etc. Adding Execute / ExecuteAsyncĪs a result, in an upcoming (not yet released) version, the plan is to add some new methods to StackExchange.Redis to allow more direct and raw access to the pipe for example the rejson module adds a JSON.GET command that takes a key to an existing JSON value, and a path inside that json - we can invoke this via: string foo = (string)db.Execute( ![]() If you're interested in Redis, you should go check it out! There's already a gallery of useful modules started by Redis Labs - things like JSON support, Machine Learning, or Search - with an option to submit your own modules to the community.Ĭlearly, my old approach of "manually update the API when new releases come out" doesn't scale to the advent of modules, and saying "use Lua to run them" is. This allows anyone to write a module that does something interesting and useful that they want to run inside Redis, and load that module into their Redis server - then invoke it using whatever exotic commands they choose. Along comes ModulesĪ key feature in Redis 4.0 is the introduction of modules. if that isn't enough, you can always use hack by using Lua to do things at the server directly. it makes it hard to ensure that key-based sharding is being implemented correctly (as to do that you need to know with certainty which tokens are keys vs values vs command semantics)įor all these reasons, StackExchange.Redis has historically offered a more method-per-command experience, allowing full intellisense, identification of keys, helper enums for options, santity checking of operands, and various scenario-specific optimizations / fallback strategies.it prevents the library offering any special-case optimizations or guidance.it presents a higher barrier to entry, as users need to learn the redis command semantics.Some client libraries expose a very raw API surface, leaving the individual commands etc to the caller - this has the advantagee of simplicity, but it has disadvantages too: As the primary maintainer of StackExchange.Redis, new releases also bring me some extra work in terms of checking whether there are new features that I need to incorporate into the client library. Redis 4.0 is in RC 3, which is great for folks interested in Redis. This is largely a brain-dump of my plans for Redis 4.0 Modules and the StackExchange.Redis client library.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |