Redis 6 related new features support related implementation

[KamranShahid]

Not a bug but just a query.
Are there any working for supporting new features in redis 6.0
just heard following buzz word in redis conference

Redis graph,Redis search,Redis gears,Redis AI,Redis bloom,Redis Json,Redis Time series, Redis Modules, Redis Client Caching e.t.c.
Streams, Queues, Pub/Sub

[mgravell]

Hi. Most of those are "modules", meaning: bolt ons to redis. Since anyone can write their own modules, we don't build module support directly into the library but: - you can invoke any module method via "Execute" - some modules may have dedicated support in libraries that build on this one, for example NRediSearch for the search module. Streams and pub/sub are core redis features are are supported directly in the library.

…

On Tue, 12 May 2020, 18:55 Kamran Shahid, ***@***.***> wrote: Not a bug but just a query. Are there any working for supporting new features in redis 6.0 just heard following buzz word in redis conference *Redis graph,Redis search,Redis gears,Redis AI,Redis bloom,Redis Json,Redis Time series* *Streams, Queues, Pub/Sub* — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1459>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAEHMCDWATMXORB7VC25BTRRGESVANCNFSM4M7BJ4CQ> .

[Turnerj]

While not related to the features listed above but still a new feature in Redis 6.0, "server-assisted client side caching". Basically the server can send down an "invalidate" message for a specific key if client tracking is turned on.

I have a caching library which currently uses pub/sub to communicate between instances for cache invalidation though this new feature in Redis could be useful/better for the same functionality.

Is this a type of feature that you think would be a good fit for the library? Happy to help contribute to this feature too, just curious if you want this functionality in the library. 🙂

[mgravell]

We have a caching piece internally that we've been meaning to drop into the lib for ages, but we've been holding off because of this feature. Which doesn't mean that our implementation is partoctut good - my point is simply "it is already on our radar".

Some complications:

• my hunch is that we should do this via "optin" mode using a new CommandFlags entry that sends a CACHING pre-command
• we have plans to look at both RESP3 and connection pooling (and by "plans" I mean "it is fully prototyped"); we just need to be clear about the redirect client id
• and think about how reconnects work for both the data and pub/sub connection
• and think about how it is enabled in the first place; is it simply that the first CommandFlags.Caching (new option) seen on a connection does the extra setup bits? That's probably the simplest option, and avoids lots of complexities related to both pooling and reconnects

[Turnerj]

Awesome to hear @mgravell - I figured you probably would as I know your caching solution on SO does something similar already with cache invalidation through pub/sub.

While I'm no Redis expert, if there is anything I can do to help build/test anything related to this, I'm keen to do so as I think it would be useful for my caching library too.

[maloo]

When can we expect to see initial RESP3 support? I'm just about to write a Redis Timeseries extension on top of ExecuteAsync and would appreciate getting a IReadOnlyDictionary<> back instead of a multi dimensional RedisResult array.

[NickCraver]

A lot of individual features have issues or PRs open for adding (and more are in point releases) - closing this out as a meta issue since it's covered.

@maloo to answer the RESP3 question: there's no timeline on RESP3 at the moment given other priorities (e.g. client side caching) and the minimal wins we get (since most users are on RESP2, we can't drop it - so we're only adding complexity). It's something we want to look at, but isn't high priority.