FusionCache: Fail-safe getting or setting featuring a default value

This is awesome!

Also, regarding the documentation: here is a new dedicated page about core methods.

What do you think @clxx ?

I’ve release v0.1.3 containing this very feature 🎉

Added param failSafeDefaultValue to GetOrSet[Async]

In the commit 1900d96 I added a new failSafeDefaultValue param to the core GetOrSet method. This is a way to specify an optional default value to use when fail-safe is enabled and something goes wrong with the factory execution (a timeout, an exception, or anything else).

This sounds great!

The type of the param is the new MaybeValue<TValue> which is logically similar to a Nullable<T>, but which can be used with any type including reference types (somewhat like the maybe/option monad, if you are into functional programming): since it is a struct it does not allocate on the heap, so less heap usage when not used. It also implements implicit conversion to/from TValue so you don’t have to be explicit when using it.

I really like the idea of using such a MaybeValue<TValue> here…

Documentation

Initially you (@clxx ) said this:

but from the otherwise excellent documentation and the example code alone it is not clear, how to combine these features

I thought about this a lot and I think that, on top of adding the new failSafeDefaultValue param to actually combine factory + default value, I should better clarify in the documentation the difference between GetOrSet and GetOrDefault. I was thinking about something like this:

The GetOrSet methods GET a value from the cache and, if not there, either calls a FACTORY or use the provided VALUE, after which it SET the new value in the cache and returns it. If you provide a factory and enable fail-safe, you can also specify a failSafeDefaultValue: if you do so and anything goes wrong with the factory execution you would still be sure the method call does not throw and would ALWAYS returns something.

On the other hand the GetOrDefault method GET a value from the cache and, if not there, returns a DEFAULT VALUE but it will NEVER set a new value in the cache. This means any successive call would still NOT find the cache entry and maybe call the factory again.

In short:

• with GetOrSet you GET what’s in the cache, and maybe something will be SET there
• with GetOrDefault you GET what’s in the cache, or a default value will JUST BE RETURNED

What would you think of an explanation like that?

First of all, thank you, since this makes it much clearer. For me, this explanation is perfect - you may only add one half sentence about the new failSafeDefaultValue being “returned whenever anything goes wrong with the factory execution” and there is no usable fallback entry anymore (initally or due to final expiration).

I think the “negative cache” concept at the moment is something to think about. It is causing me some friction for a few use cases in an existing project where I have a bunch of unit tests asserting the “negative cache” behavior. As I replace with FusionCache I am not 100% sold on “negative-cache” being a feature request. With all the features in FusionCache I just need to keep using it for a while to decide if I need that “negative cache” feature. I have been in this code base for a solid week and experimenting with it in a project. I just need to let all this marinate for some time.

@jodydonetti thanks for sharing this project with us!
I will update my metrics PR to this code and try to get some experimenting time with this change.

Hi @clxx , I’ve just pushed a couple of new features.

Added param failSafeDefaultValue to GetOrSet[Async]

In the commit 1900d960090d69382ed06688270d0d4e9fd6438b I added a new failSafeDefaultValue param to the core GetOrSet method. This is a way to specify an optional default value to use when fail-safe is enabled and something goes wrong with the factory execution (a timeout, an exception, or anything else).

The type of the param is the new MaybeValue<TValue> which is logically similar to a Nullable<T>, but which can be used with any type including reference types (somewhat like the maybe/option monad, if you are into functional programming): since it is a struct it does not allocate on the heap, so less heap usage when not used. It also implements implicit conversion to/from TValue so you don’t have to be explicit when using it.

Of course I added all the needed overloads to be able to work with TimeSpan instead of explicit options etc, and also the ones needed to map all the old methods signatures (without the new param) and related overloads, so everything should - in theory 😅 - compile just like before without any change.

Added a new GetOrSet[Async] method with a direct value (instead of a factory)

Kinda related, some people asked me how to get a value from the cache and, if not there, set a value directly without providing a factory, without the useless lambda allocation and with a less cumbersome way to call it. So in f7c648033f53630ccbf9fa1b7442303859c2265f I added such new core method (and related overloads for TimeSpan, etc).

Practical example

Before, if we had a value to use when a cache entry was missing, we had to do this:

var foo = cache.GetOrSet("foo", _ => 42, TimeSpan.FromMinutes(2));

Now instead we can do this:

var foo = cache.GetOrSet("foo", 42, TimeSpan.FromMinutes(2));

Documentation

Initially you (@clxx ) said this:

but from the otherwise excellent documentation and the example code alone it is not clear, how to combine these features

I thought about this a lot and I think that, on top of adding the new failSafeDefaultValue param to actually combine factory + default value, I should better clarify in the documentation the difference between GetOrSet and GetOrDefault. I was thinking about something like this:

The GetOrSet methods GET a value from the cache and, if not there, either calls a FACTORY or use the provided VALUE, after which it SET the new value in the cache and returns it. If you provide a factory and enable fail-safe, you can also specify a failSafeDefaultValue: if you do so and anything goes wrong with the factory execution you would still be sure the method call does not throw and would ALWAYS returns something.

On the other hand the GetOrDefault method GET a value from the cache and, if not there, returns a DEFAULT VALUE but it will NEVER set a new value in the cache. This means any successive call would still NOT find the cache entry and maybe call the factory again.

In short:

• with GetOrSet you GET what’s in the cache, and maybe something will be SET there
• with GetOrDefault you GET what’s in the cache, or a default value will JUST BE RETURNED

What would you think of an explanation like that?

Closing thoughts

Before publishing a new package version on nuget.org I would like to know what you all think about it ( @clxx @JoeShook @alb-xss ). Do you see any problems? Do you think the MaybeValue<TValue> is a good or bad idea?

Hi all, I think I got the right design now.

I’m doing some more tests and perf tuning, and in the next few days I’ll push the new feature so you can play with it and give me a feedback.

Wow, lots of food for thoughts, thanks!

Let me marinate these ideas, maybe sleep over them and the possible consequences a little more, and I’ll come back to you with something.