-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Cache tags beyond groups #18650
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
How would tags be applied to cache items? We don't really have an ItemInterface like symfony does. |
Yeah, I think we would need to open this up for such an interface approach maybe? |
I know from other frameworks, that tagged cached items are not supported by all (but most) engines (primarily Redis, Memcache and APCu) - so this would also be a feature which can only be added to certain engines. But yes, I'd like that since I also had situations, where I wanted to tag certain - different - cache keys with the same tag to make it easier to delete a certain group of cache entries (e.g. all cache keys of a certain user ID) |
The way symfony solved this seems to be a TagAwareAdapter
This should make it work for each engine in the end, since the tag dimension stores the references on the actual cache items. |
It would also be nice if we then adopted the idea of built in Stampede prevention.
|
If we didnt plan on adding more serious cache functionality, I guess it would be simple enough to just re-use symfony components here. // src/Service/SymfonyCacheService.php
namespace App\Service;
use Symfony\Component\Cache\Adapter\RedisAdapter;
use Symfony\Component\Cache\Adapter\TagAwareAdapter;
use Redis;
class SymfonyCacheService
{
protected $cache;
public function __construct()
{
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
$this->cache = new TagAwareAdapter(new RedisAdapter($redis));
}
public function remember($key, callable $callback, array $tags = [], float $beta = 1.0)
{
return $this->cache->get($key, function (CacheItemInterface $item) use ($callback, $tags) {
$item->tag($tags);
return $callback();
}, $beta);
}
public function invalidateTags(array $tags)
{
$this->cache->invalidateTags($tags);
}
} // src/Controller/ArticlesController.php
use App\Service\SymfonyCacheService;
public function view($id)
{
$cacheService = new SymfonyCacheService();
$cacheKey = 'article_' . $id;
$article = $cacheService->remember($cacheKey, function () use ($id) {
return $this->Articles->get($id, ['contain' => ['Comments']]);
}, ['article', 'comment']);
return $this->set(compact('article'));
} // src/Model/Table/ArticlesTable.php
use App\Service\SymfonyCacheService;
public function afterSave($event, $entity, $options = []): void
{
if ($entity->isNew() || $entity->isDirty()) {
$cacheService = new SymfonyCacheService();
$cacheService->invalidateTags(['article']);
}
} |
This seems simpler to implement, as it could be a setting on the engine.
The tagging use cases can be handled with additional cache engine configurations. Instead of tagging specific keys, those keys can be put into different cache profiles that can be cleared independently of other profiles. I'm interested in knowing more about the other scenarios you have though. |
Then I guess we could just focus on that part for now. That also seems like the more important issue anyways, in terms of uptime reliability. |
Uh oh!
There was an error while loading. Please reload this page.
Description
https://book.cakephp.org/5/en/core-libraries/caching.html
We seem to have groups.
Those are however linked to the engine itself, not individual cache entries.
I think given this they are quite limited in its use - and not very practical.
In other systems they use cache tags, and those work on the entries themselves
https://symfony.com/doc/current/components/cache/cache_invalidation.html#using-cache-tags
That makes it possible to store them with specific entries, and then be able to invalidate them throughout that engine.
This is usually what they makes them so useful and practical, you dont need to set up engine configs to get different tags to work, and invalidating them.
We lack this functionality it seems.
Symfony added this with v4 it seems ( symfony/symfony#28096 + symfony/symfony#28097 )
The text was updated successfully, but these errors were encountered: