Multiple types with same key are returned as null from cache - last in wins?

[alastairtree]

Multiple types with same key are returned as null from cache - last in wins?

[alastairtree]

We could embed the type into the key but that would break the capability to cache sync and retrieve it from the async method feature which is quite convenient in a sync/async environment, so inclined not to and make the developer choose the right key. The behaviour you describe does help the developer to catch situations where they have missused the same key.

Either when you cache a new thing of different type it should:
1 - returns null as now, (will probably become a null ref runtime exception in users code)
2 - Throw an exception from inside lazycache
3 - override the thing in the cache with the new thing of different type (no exception - assumes the developer knew what they were doing - last in wins)

My preference would be option 3?

[avanish-fullstack]

Would agree with #3 , @alastairtree , giving the power in the hands of the developer to decide what the intention was rather than throwing an exception

[NeilMacMullen]

Thanks for looking at this. It it's helpful I can describe my use-case....

I have an IoT application where multiple record types are associated with each sensor. The sensor Id is the most useful key to use to index these records and it's therefore a convenience to store everything associated with a particular sensor in a single cache. So for sensor "1234" the cache might contain a location-record and a power-record. All the client libraries I'm using are using generics and so storing/fetching by key+type is fairly natural. As it happened, I just wrote some extension methods to get the behaviour I wanted....

/// <summary>
    /// Provides wrappers around LazyCache that allow the same key to be used for different object types
    /// </summary>
    public static class CacheExtension
    {
        private static string MakeKey<T>(string key)
        {
            return $"{typeof(T)}" + key;
        }
        public static void SafeAdd<T>(this IAppCache cache,string key,T val)
        {
            cache.Add(MakeKey<T>(key),val); 
        }

        public static Task<T> SafeGetOrAddAsync<T>(this IAppCache cache, string key, Func<Task<T>> fetcher)
        {
            return cache.GetOrAddAsync(MakeKey<T>(key), fetcher);
        }

        public static T SafeGetOrAdd<T>(this IAppCache cache, string key, Func<T> fetcher)
        {
            return cache.GetOrAdd(MakeKey<T>(key), fetcher);
        }
    } 

While I'm commenting.... you probably have good design reasons for doing it this way but it would be a nicety (at least for the sync version) to have a GetOrAdd prototype that takes a Func<string,T> so that the nicer method-group syntax could be used....

var foo = cache.GetOrAdd("key", FetchFoo);
Foo FetchFoo(string key) {..}

[alastairtree]

This will be fixed in 2.0.3 so that last in wins and if you cache 2 types with the same key, the second type will force the eviction of the first. However unless you have a really good reason, always use different keys for different types.

Thanks