Closed jodydonetti closed 6 months ago
Thanks Alberto! I'd like to thank @albx that allowed me to stumble upon this special case: he's been kind enough to invite me to one of his live coding events as a guest and see him move his first steps with FusionCache live.
That has been a really nice experience, and on one hand it allowed me to validate that the various design and naming approaches I took along the years have been solid and intuitive, and on the other hand it made me discover a small niche scenario that could've been made even better (this one).
My pleasure @jodydonetti. It has been a really nice and interesting experience and I'm really happy that this experience gave a little contribution to this project :)
Hi all, I just released v1.0.0-preview1 🥳
Please try it out so we can spot any potential issue before the official v1.0
, thanks!
Hi all, I just released preview2
🥳
Please give it a try, thanks!
Hi all, I've finally released v1.0 🥳
Feels a little unreal tbh, but yep: v1.0 is out.
Problem
With the introduction of the builder in v0.20 FusionCache got a nice way to configure the various options and components, in a very flexible way.
In one particular scenario though, it is possible to specify something incoherent: a single instance with multiple
CacheName
s, by using both the high levelAddFusionCache("MyCache")
and theWithOptions(...)
methods, like this:This does not make any sense of course, but it is a case that is currently not proactively detected by FusionCache, so the runtime behaviour may lead to some surprises, which is not nice.
A slightly different and more subtle way to fall into this trap is this:
This may happen because the developer didn't notice the
AddFusionCache(name)
overload, and thought about setting theCacheName
via theWithOptions(...)
method.It should be noted that, while it may seems like a valid way to specify the
CacheName
and so it should be supported, that is not the case because theCacheName
specified via theAddFusionCache(name)
is fundamental since the name is used for different things while building the FusionCache instance, like when trying to get named options viaIOptions<FusionCacheOptions>
and more things internally. Finally, in crucial places like these, it's normally better to have one correct way to setup things, so the official way remainsAddFusionCache(name)
.Solution
An
InvalidOperationException
exception should be thrown when trying to instantiate the cache, typically via theIFusionCacheProvider.GetCache(name)
method.A slightly different case is for registering the default cache (a FusionCache with the default name, which can be resolved by simply having an
IFusionCache
param in a ctor instead of having to use anIFusionCacheProvider
param): in this case the exception would be thrown by .net when trying to resolve the param.Finally, xml docs for the related methods and exception thrown should be made better to account for this scenario, and ideally they should give clear instructions about how to correctly register named caches or to avoid changing the cache name via the
WithOptions(...)
when using the DI/builder approach.Thanks Alberto!
I'd like to thank @albx that allowed me to stumble upon this special case: he's been kind enough to invite me to one of his live coding events (italian language) as a guest and see him move his first steps with FusionCache live.
That has been a really nice experience, and on one hand it allowed me to validate that the various design and naming approaches I took along the years have been solid and intuitive, and on the other hand it made me discover a small niche scenario that could've been made even better (this one).