fetch executes fallback if cached value is nil

[karlseguin]

I couldn't find this behavior documented anywhere. The documentation says that the fallback should only be executed "on cache miss". This doesn't seem to be the case though. Obviously it has to do with the fact that get/2 returns {:ok, nil} which is the condition to execute the fallback.

If nil cannot be used as a value, I think it's worth highlighting in the documentation.

> import Cachex.Spec
> Cachex.start_link(:cache, limit: 100, expiration: expiration(default: 10000000))            
{:ok, #PID<0.462.0>}

> Cachex.ttl(:cache, "key")
{:ok, nil}

> Cachex.put(:cache, "key", nil)
{:ok, true}

> Cachex.ttl(:cache, "key")     
{:ok, 9998680}

> Cachex.fetch(:cache, "key", fn -> raise "should not be called" end)             
{:error, "should not be called"}

[whitfin]

If you want to PR this somewhere in docs, go ahead. The use of nil generally represents no value, so putting nil into the cache is a weird pattern in the first place; the only case I can think of is checking presence, in which case using something like true is probably better.

It's pretty much just a side effect from ETS itself, it's not something done in this lib. If an empty key comes back from ETS, it's nil. There's no other way to communicate a cache miss other than nil.

[whitfin]

I'm going to close this out, because this is pretty much ETS behaviour. If someone places nil in ETS, it's pretty much the same as nothing being there. There's a chance we can figure out a good way to work around it if more people need it, but I would suggest using something other than nil!

[axelson]

@whitfin I just spent a good amount of time trying to figure out why values that I expected to be cached were not in fact cached. I wonder if a way to surfaced this issue to users would be to log a warning when the fetch fallback function returns: {:commit, nil} since that result will not actually be committed to the cache. Any thoughts?