Cache: conditionally "remember" and "rememberForever"

[gehrisandro]

Sometimes I need to cache a value depending on the current situation. For example, a value should be cached for regular users but not for admins.

At the moment, the way to achieve this is by having a condition before calling the cache:

if(auth()->user()->isAdmin()){
    return $this->heavyCalculation();
}

return Cache::remember(
    key: 'heavy-calculation',
    ttl: 3600,
    callback: fn () => $this->heavyCalculation(),
);

In my opinion, it would be nice to have something like this, where the condition can be passed as the first parameter.

return Cache::rememberWhen(
    when: !auth()->user()->isAdmin(),
    key: 'heavy-calculation',
    ttl: 3600,
    callback: fn () => $this->heavyCalculation(),
);

Another approach would be a fourth optional parameter on the existing remember method for the when condition.

return Cache::remember(
    key: 'heavy-calculation',
    ttl: 3600,
    callback: fn () => $this->heavyCalculation(),
    when: !auth()->user()->isAdmin(),
);

The same would apply to rememberForever().

What do you think?

If I am not the only one, having this need, I am happy to PR the feature.

There was a similar discussion before, but it went off-track, so I decided to create a new one. See: #48890

[bulletproof-coding]

if(auth()->user()->isAdmin()){
    return $this->heavyCalculation();
}

return Cache::remember(
    key: 'heavy-calculation',
    ttl: 3600,
    callback: fn () => $this->heavyCalculation(),
);

In my opinion this is the best option because calling the remember implies all its parameters to be processed, so if the key is a concatenation or the ttl is calculation then those will not be executed.
So why call it instead of early return?

[gehrisandro]

Because of the readability.

The early return enforces you to extract the heavy task and can not be done inline (or it is a duplicate).

[bulletproof-coding]

I understand. But you are using a cache facade to do something that sometimes does not touch the cache in this case:)

[henzeb]

It would be useful if Cache would implement the Conditionally trait. Then you could do Cache::when($isUser)->driver('array')->remember(...);

[Rike-cz]

Yes! That's what I am looking for! 👍

[browner12]

I have needed this a couple times and had always intended to PR something in, so I'd be for it. The Conditionable trait would be interesting because then you could get this in ASAP without needing to wait for the next major version like you would with the signature change.

[gehrisandro]

Adding a parameter to the method signature should not be breaking.

But I will check out the conditional trait. But I am not sure if this is the right choice. Lets see.

[browner12]

yah, I tried it with Conditionable, I don't think it's a feasible solution.

[bshrader-snow]

I have a similar need to this, but want to propose an alternative solution. My idea is to add two new methods to the cache facade:

/** Executes callback and returns its value, ignoring any cached values */
Cache::withoutCache(Closure $callback);
/** Executes callback and returns its value, revalidating any cached values matching keys */
Cache::forceRevalidate(Closure $callback);

// Basic Examples

Cache::put('my-cache-key', 'some-other-value');

function getSomeCachedValue() {
    return Cache::remember('my-cache-key', function () {
        return 'some-value';
    });
}

// Returns 'some-value' without reading or writing to cache - 'my-cache-key' retains 'some-other-value'
Cache::withoutCache(function () {
    return getSomeCachedValue();
});

// Returns 'some-value' and result is stored in 'my-cache-key'
Cache::forceRevalidate(function () {
    return getSomeCachedValue();
});

I believe this is a more generic solution to the problem, so should have a greater variety of use cases. My own use case is that I have a lot of functions which return Cache::rememberForever and I often need to revalidate the cached value when one of the dependencies changes (which I typically do on a queued event listener). Copying (or in many cases deriving) cache keys in multiple places is rather error prone, and my problem gets worse when a memoized function calls another memoized function. Having a way to force revalidation of any keys accessed in a closure would make my problem much easier to solve, and would not be easily addressed by the other proposed solutions.

One thing I'm unsure of in this proposal would be whether and how to support filtering the behavior (e.g. by store, tag, key, etc) if you wanted to only revalidate certain values while still using the cache for others inside the closure. I'm also unsure how methods like Cache::put and particularly Cache::get should best respond inside the closure.

[browner12]

I submitted a PR for this that was rejected: #52702

[bshrader-snow]

That PR wouldn't have solved my problem anyway. I have hundreds of call sites to remember (some of which have additional calls to remember further down the call stack) that I need to revalidate on events, so my revalidation conditions aren't easily known when I actually make the remember call. The best I can do right now is:

public function getExpensiveProperty(bool $revalidate = false)
{
   $cacheKey = $this->getExpensivePropertyCacheKey();
   if ($revalidate) {
       Cache::forget($cacheKey);
    }

    return Cache::remember($cacheKey, function () use ($revalidate) {
        return ... + $this->getOtherExpensiveProperty($revalidate);
    });
}

I would have to make that refactor in hundreds of places, always paying attention to whether or not I need to pass the revalidate flag around to each of my getters. That's why I proposed adding Cache::forceRevalidate($myModel->getExpensiveProperty()), which I could call from my event listener without needing to keep track of which calls further down the stack would additionally need revalidated.