Revert Redis Tagged cache implementation

[AidasK]

Laravel Version

10.x & 11.x

PHP Version

8.x

Description

It's well known that laravel tagged cache was removed from the docs a couple of months ago and it looks like a too harsh of a decision for a feature which was in the core for 10 years. So I would like to propose an alternative approach which would not require a lot of work from the devs.

I suggest to revert laravel redis tagged cache to 9.x version. It had no bugs with consistency. It always worked while flushing the tagged cache and it always returned the fresh data. Of course it had leaks, but it was not causing the application to misbehave. This feature was in laravel core for 10 years now and for most of us it was usable. So old implementation can still be used, but some caution messages should be added to the docs.

So my suggestion is to:

• Bring back the docs.
• Revert implementation for redis to 9.x or even better to use Symfony Cache which supports tags.
• In case of 9.x, mention that tagged cache does not flush the tag keys and values and they might build up over time. So tagged cache should not be used with dynamically created tags. E.g. used id should not be used as a tag. Though tag cache won't be a problem if it's used with static code enums or constants as they don't scale infinitely.
• In case of 9.x, add a requirement to always use an expiry date with the tagged cache to prevent running out of memory. So instead of using cache forever, you should cache only for one week or a month.

So old tagged cache is still usable, though developers have to be aware of the shortcomings. At current state redis tagged cache is unusable as it does not guarantee consistency so memory leaks are not even a concern if it's not working.

Steps To Reproduce

#48078

laravel/docs@63dde39

[jspicee]

Revert implementation for redis to 9.x with warnings would be the best for me

[binaryfire]

This was my reply to Taylor in the docs commit:

We have loads of apps that rely on cache tags.... It's a crucial feature for managing caching in any large scale app, or multi-tenant setups etc.

If you're open to breaking changes in v11, I think refactoring tags to work how they do in every other platform (i.e. much more simply) would be great. The complexity in Laravel comes from how multiple tags work. The readme of this package explains it well: https://github.com/swayok/alternative-laravel-cache.

I never understood the logic behind Laravel's implementation. Tags should be independent - i.e. you can tag a single cache object with multiple tags, then purge that object using any of those tags. So you could tag a post with posts and tenant_1, and if you purged either the posts or tenant_1 tag that object would be removed.

[AidasK]

Laravel follows https://www.php-fig.org/psr/psr-16/ e.g. SimpleCache interface while symfony follows PSR-6, which is compatible with psr-16. So it should not be hard to write a driver as explained here https://laravel.com/docs/11.x/cache#writing-the-driver

As for tags, laravel has not documented how to extend them, but it's actually quite simple. Instead of extending the Illuminate\Contracts\Cache\Store; contract, you should extend Illuminate\Cache\TaggableStore and override tags method with symfony tags implementation.

So it's actually not that hard to solve and IMO this solution should be a good replacement for laravel native cache implementation.

[eldair]

This is what I came up with today, it might be helpful to someone (ofc every input is appreciated) https://github.com/eldair/laravel_symfony_cache/tree/main/extensions/SymfonyRedisCache
I took some ideas from https://github.com/1FF/laravel-mongodb-cache

[eldair]

I had to make changes to clean keys because laravel doesn't follow ether psr-6 or psr-16 when it comes to cache keys - laravel uses : for various internal cache keys (like maintenance mode) which is not allowed by both PSRs.

[gerardnll]

Thanks for the implementation! Is it me or setting \INF when calling ->get() (https://github.com/eldair/laravel_symfony_cache/blob/main/extensions/SymfonyRedisCache/RedisTaggedCache.php#L64) makes the cache revalidate always? Maybe you want to set 0 although that would disable the probabilistic early expiration.

[eldair]

It should recalculate since it is in put method, if it doesn't recalculate and the item with that key already exists it will not be updated to the desired value from put method.

[skills-up]

Has a decision been reached on this yet?

I'm a developing a multi-tenant SaaS application, and imagine my surprise when the tags suddenly went missing from the docs.
At this point, I'm unsure of their availability in the framework, and afraid to use them even if supported.

A tagged cache is required for some significant chunks of data, that are rarely updated. I would like to cache them all forever, and flush the cache only when any corresponding entry is updated.

[henzeb]

Not sure how you've set them up. if you have multiple tags, I can't help you atm, but maybe you could try https://packagist.org/packages/henzeb/laravel-cache-index

[wilsenhc]

Thank you @henzeb, just saved my life! I will take a better look at the source code later and contribute with anything I can!

[byErikas]

bumping this