jmenziessmith / tagcache.redis Goto Github PK

Hi,

So we have a good selection of serializers, migrated to StackExchange and good test coverage.
What do you suggest are the next steps?

I would personally love to be able to use Protobuf without having to manually decorate every cached object so I'm going to try to see if using reflection to setup the serialization is worth it.

I guess there is still a bit of cleaning-up/refactoring we can do but as it is, it's working well in tests on my applications.

After that I guess it would be great if someone jumped in to make a small GitHub page to showcase the library and how to use it.

Except for NCache (which is commercial), there aren't many .NET caching libraries that support tags so there's that.

Hi @jmenziessmith,

As you mention, it would be preferable to move away from Booksleeve towards StackExchange.Redis like StackExchange has done.

I have run the current unit tests with the Json serializer and because CacheItem is serialized and the Value property is of type object, Value's type is lost on deserialization (it becomes a dynamic Newtonsoft.Json.Linq.JObject).

It works with the Binary serializer as it stores metadata but not Json.

All the unit tests (except the serializer-specific ones) should be run with all 3 serializer providers.

To solve the issue I think I'm going to make CacheItem generic which will also remove a cast in Get(string key).

Repro:

Reference TagCache.Redis.Json.Net

void Main()
{
    var redisConnMgr = new TagCache.Redis.RedisConnectionManager("localhost");
    var config = new TagCache.Redis.CacheConfiguration(redisConnMgr)
    {
        Serializer = new TagCache.Redis.Json.Net.JsonSerializationProvider(),
    };
    var cacheProvider = new TagCache.Redis.RedisCacheProvider(config);

    cacheProvider.Set("foo", new Foo(), DateTime.UtcNow + TimeSpan.FromMinutes(5));
    /*
    {
        "Value": {
            "Bar": "baz"
        },
        "Key": "foo",
        "Tags": null,
        "Expires": "2016-01-13T15:10:21.837778Z"
    }
    */

    cacheProvider.Get<Foo>("foo");
    // ERROR:
    // Could not create an instance of type 
    // TagCache.Redis.Interfaces.IRedisCacheItem`1[Foo].
    // Type is an interface or abstract class and cannot be instantiated.
}

public class Foo
{
    public string Bar = "baz";
}

Expected outcome: json at redis key "foo" successfully deserialized into type Foo.

Actual outcome: json.net error:
Could not create an instance of type TagCache.Redis.Interfaces.IRedisCacheItem`1[Foo]. Type is an interface or abstract class and cannot be instantiated. Path 'Value', line 1, position 9.

I'm working out some issues with my AutoProtobuf library, specifically support for DataTable and other things. I was wondering if we could do without wrapping items inside a RedisCacheItem.

It would save a tiny bit of overhead, allow using specialized serializers like protobuf-net-data. RedisCacheItem is not exactly indispensable in the current implementation and adds a few headaches including the attribute decoration issue that you want to solve with a factory.

Is there a technical reason why StackExchange.Redis.StrongName was chosen (vs StackExchange.Redis)?

The issue we are having is we cannot use this package and interop with our existing SE.Redis-dependent code (we have no need for strongly signed dependencies).

For example:

InHouseRedisUtil.dll (depends on StackExchange.Redis):

void TryRedis(Action action)
{
  try
  {
    action();
  }
  catch(StackExchange.Redis.RedisConnectionException e) // <-- VANILLA SE.Redis here
  {
    // bunch of custom logic to requeue the operation,
    // avoid loss of data, etc, etc
  }
}

Application code (depends on TagCache.Redis.dll and InHouseRedisUtil.dll):

InHouseRedisUtil.TryRedis(() => SomeTagCacheRedisOperation());

The two codebases cannot interop even though it's the exact same SE.Redis code underneath.

On Windows 7 with Redis 2.8.17 (x64), the ItemExpires_Tag_RemovedFromCache test fails.
The "*:expired" pattern sub is never called.