attempt to solve the concurrency issues with get_or_set

[PoByBolek]

This should fix issue #149.
When there is no stale value to return, one thread tries to compute func()'s result while all other threads wait for it to complete.

[PoByBolek]

Apparently not... I can't even reproduce this on my machine :(

[victorvess]

I originally left a comment asking why we wouldn't use Blocking, but I think I get what you're doing here... think I had just a minor tweak I suggested inline with regard to caching of None

[victorvess]

Suggested change

	if value is not None and is_fresh:
	if is_fresh:

I suggest maybe we leave the None check out of here because func could explicitly return None here

[PoByBolek]

I guess I was thinking if get() returns None, then the cached value has expired and that should have precedence over the is_fresh value. Because the Django docs explicitly advise against storing None in caches:

We advise against storing the literal value None in the cache, because you won’t be able to distinguish between your stored None value and a cache miss signified by a return value of None.

So nobody would ever do that, right? ;-)

Moreover, when I do

cache.get_or_set('foo', lambda: 1)
cache.delete('foo')
cache.get_or_set('foo', lambda: 2)

The final get_or_set() would return None with your changes (because the __fresh__foo key wasn't deleted), where I would expect it to return 2 instead.

[victorvess]

I guess I was thinking if get() returns None, then the cached value has expired and that should have precedence over the is_fresh value. Because the Django docs explicitly advise against storing None in caches:

We advise against storing the literal value None in the cache, because you won’t be able to distinguish between your stored None value and a cache miss signified by a return value of None.

So nobody would ever do that, right? ;-)

Hah, nice I was not aware of this advice that's good to know

Moreover, when I do

cache.get_or_set('foo', lambda: 1)
cache.delete('foo')
cache.get_or_set('foo', lambda: 2)

The final get_or_set() would return None with your changes (because the __fresh__foo key wasn't deleted), where I would expect it to return 2 instead.

https://martinfowler.com/bliki/TwoHardThings.html

Okay makes sense. Yeah I guess this could lead to making delete try to clean up fresh keys too but only get_or_set does those and its another edge case to check and at some point we're back and forth with redis so much are we even saving time caching? 😄

Thanks for the response I'm good with this, now we just need to get your PR accepted cuz this is impacting me too and I would love to not maintain a fork for my company hehe