IDistributedCache should include StringSet/SetString

[shanselman]

Right now IDistributedCache is a generic interface that's presumably meant to support lots of distributed caches. It's pretty clear, though, that Redis is going to be 80% or more of the usage. Not to mention Azure has a Redis As A Service.

IDistributedCache has SetAsync which just takes bytes...as it is there's no easy way to add overloads/extensions to get at the underlying Redis implementation and set strings.

As we are today, you can't set from ASP.NET Core and GET from the CLI. redis-cli supports SET and GET with strings. This makes debugging with the CLI a hassle.

GetString and SetString are atomic enough that they should be added to IDistributedCache.

/cc @NickCraver @mgravell @DamianEdwards @rustd

[Tratcher]

It's worth noting that we don't just store the bytes, we store our own complex object containing the expiration information: https://github.com/aspnet/Caching/blob/dev/src/Microsoft.Extensions.Caching.Redis/RedisCache.cs#L81-L88
So even if we added a string version, I don't know if you'd be able to view it from the CLI. Have you tried to hack it in yet?

[mgravell]

Hacky but possibly workable:

static Task SetAsync(this IDistributedCache cache, string key, string value, DistributedCacheEntryOptions options) {
    return cache.SetAsync(key, Encoding.UTF8.GetBytes(value), options);
}

On the CLI front: looking at that script, as long as the caller knows to use HGETALL {key} rather than GET {key}, that should actually be usable and readable. Unlike our even hackier in-house middleware at stack that is actually a single blob (per key) of a protobuf-encoded object that (like you) has optional sliding expiration and may or may not have the payload gzip compressed!

As a side note, I so want to C#6-ify that RedisCache.cs linked above...

    private const string SetScript = $@"
            redis.call('HMSET', KEYS[1], '{AbsoluteExpirationKey}', ARGV[1], '{SlidingExpirationKey}', ARGV[2], '{DataKey}', ARGV[4])
            if ARGV[3] ~= '{NotPresent}' then
              redis.call('EXPIRE', KEYS[1], ARGV[3])
            end
            return 1";

;p

[shanselman]

Thanks Marc...I guess after "the basics" everyone starts piggybacking
metadata on top or putting it in the serialization format, don't they?

HGETALL works for my basic learning/teaching scenario, thanks!

On Tue, Mar 22, 2016 at 2:51 PM, Marc Gravell notifications@github.com
wrote:

Hacky but possibly workable:

static Task SetAsync(this IDistributedCache cache, string key, string value) {
return cache.SetAsync(key, Encoding.UTF8.GetBytes(value));
}

On the CLI front: looking at that script, as long as the caller knows to
use HGETALL {key} rather than GET {key}, that should actually be usable
and readable. Unlike our even hackier in-house middleware that is actually
a single blob of a protobuf-encoded object that (like you) has optional
sliding expiration and may or may not have the payload gzip compressed!

As a side note, I so want to C#6-ify that RedisCache.cs linked above...

private const string SetScript = $@"
        redis.call('HMSET', KEYS[1], '{AbsoluteExpirationKey}', ARGV[1], '{SlidingExpirationKey}', ARGV[2], '{DataKey }', ARGV[4])
        if ARGV[3] ~= '{NotPresent }' then
          redis.call('EXPIRE', KEYS[1], ARGV[3])
        end
        return 1";

;p

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#169 (comment)

Scott Hanselman
Donate to fight diabetes: http://hnsl.mn/fightdiabetes

[muratg]

Putting this to 1.0.0 so that we can reconsider after RC2 ships

[RehanSaeed]

I wrote a full set of extension methods for IDistributedCache which includes Get/Set String. You may also want to consider Get/Set anything of type T (Serializes/Deserializes T to/from JSON and stores it as a string) which I also wrote. It can be found:

• Here on GitHub
• In the Boilerplate.Web.Mvc6 NuGet package.
• Included when creating a new project using the ASP.NET MVC Boilerplate project template.

See also #94

[sebastienros]

If think this should just be an extension method as Marc is suggesting and not at the interface level. The result is the same in the end for the end user. Having a set of primitive conversions like Rehan has done would be nice too.

[Grauenwolf]

If it is at the interface level, the cache provider can control how serialization works. For example, the cache may prefer to represent the data in XML or JSON format instead of binary.

[basitanwer]

Redis is going to be 80% or more of the usage

While this maybe true at the moment but nobody can predict the future. For a specific use case we can't/shouldn't change an interface which is an abstraction.

[ChrisProlls]

Just by curiosity, why IDistributedCache has no extensions methods for storing objects ? Something like Get(string key) or Set(string key, Type value) ?

[Tratcher]

@ChrisProlls just because we haven't needed them yet. Session is one of the only consumers at the moment and it uses it's own serialization logic.

[Grauenwolf]

Another use case is two-level caching.

Some caches may want to keep a subset of your object in a local cache so that it can quickly give it back to you.

The current design requires a potentially expensive deserialization process even if the object doesn't need to be fetched over the wire.

[Grauenwolf]

I don't see this interface as an abstraction at all, and that's the problem.

Instead it is specifically written for caches that use binary as their communication protocol and for cache consumers that want to control serialization.

We need a generic contract for distributed caches that can be used beyond that very narrow scenario and this isn't it.

[sebastienros]

@Grauenwolf This specific interface is not designed to support your scenario obviously, and that's fine. I suggest you create a custom service that could reuse IDistributedCache and IMemoryCache to fulfill what you need. The implementation would only have the fallback logic you are mentioning, so it should be pretty simple. Having a service that does all the things anyone could require would be a bigger problem IMO.

[basitanwer]

I agree to @Grauenwolf and sort of with @shanselman as well

void Set(string key, byte[] value, DistributedCacheEntryOptions options);

is very specific. While I would suggest the value should not be string but would also agree that it should be something other than a byte array. Would the type object suffice here ?

The better implementation IMHO would be to create a custom object and make it implicit. A similar implementation to RedisValue. https://github.com/StackExchange/StackExchange.Redis/blob/master/StackExchange.Redis/StackExchange/Redis/RedisValue.cs