[Cache] Add hierachical tags based invalidation #18646
Conversation
55bafb6 to
feee964
Compare
| } | ||
| } | ||
| $this->deferred = array(); |
There was a problem hiding this comment.
Not related in fact, a clean up that we should do on master
There was a problem hiding this comment.
this should be sent separately as it can be applied without waiting for 3.2 then
feee964 to
281a4c3
Compare
|
Comments addressed, all green in a few minutes. |
| if (!isset($tag[0])) { | ||
| throw new InvalidArgumentException('Cache tag length must be greater than zero'); | ||
| } | ||
| if (isset($tag[strcspn($tag, '{}()*\@:')])) { |
There was a problem hiding this comment.
here, / is not a reserved char anymore (of course since it's the hierachy separator), but * is, because I might need it in a later PR for adding "any-of" invalidation style (at least I missed the feat. a few times in patchwork, even though we can work around not having it). More to come in a few weeks :)
96e2d16 to
7223cd2
Compare
8827721 to
3a3527b
Compare
d692648 to
f8ca499
Compare
+1 |
45d04ae to
58c2be4
Compare
|
To be rebased on #18714 after it's merged |
58c2be4 to
f37bcd9
Compare
f37bcd9 to
238eea7
Compare
|
@nicolas-grekas You can rebase here. :) |
238eea7 to
a0776aa
Compare
|
Rebased, reviews welcomed! |
a0776aa to
d032e6d
Compare
3196ac4 to
21381f1
Compare
|
Rebased, should be ready. |
21381f1 to
56004b1
Compare
56004b1 to
d0647c8
Compare
|
I'm not comfortable with the current implementation that uses inheritance for tag management. The complexity added to each adapter is non-negligible and the work must be done for each adapter. As discussed with @nicolas-grekas, I think it would be better to use composition to add tag support. And to store tags metadata, we can/should use a dedicated storage mechanism; that way, everything is decoupled and new adapter can benefit from tags out of the box. |
|
Another benefit of separating tags from pools is cross-pools tagging, where one could invalidate a tag and get items from several pools cleared at once. |
|
I'm going to remove the hierarchical part of this tagging feature to get closer to what others have already implemented, this easing a potential future psr on cache tags, also because it will ease the implementation while not reducing the ability to invalidate hierarchical (users would just need a few more tags to do so). I'm also going to move to constant time invalidation by using a generation number per tags (same as drupal 8 cache). |
|
@nicolas-grekas sounds sensible, less is more ;) |
…pter (nicolas-grekas) This PR was merged into the 3.2-dev branch. Discussion ---------- [Cache] Add tags based invalidation + TagAwareRedisAdapter | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #18646 | License | MIT | Doc PR | - Commits ------- 19764af [Cache] Add tags based invalidation + TagAwareRedisAdapter
The implemented cache invalidation strategy is not inspired from Stash nor php-cache (but from my own good-old patchwork as stated above), so please be careful when doing direct comparisons: the concepts might look similar but aren't the same in the end. AFAIK, Stashphp and php-cache, both split the hierarchical vs tag concepts: hierarchical invalidation is implemented using special conventions when naming cache keys, and tags are plain labels used to define sets of invalidation.
Here, we have a single concept of hierarchical tags to invalidate cached items. Basically, hierarchical tags do not mangle with cache keys but add on top of PSR-6, in a powerful way for advanced cache invalidation needs (which almost everyone needs when generating web pages with excerpts from everywhere in the app's storage).
A hierarchical tag is a slash separated string, e.g.
foo/bar. One can apply as many tags as she want on a cache item before saving it by using the newCacheItem::tag($tag)method, formalized inTaggedCacheItemInterface. Invalidation is provided by theTagInvalidationInterface::invalidate($tag)method.Tags are called hierarchical because invalidation is propagated to sub-tags: invalidating the
footag is going to invalidate all items linked to tags that are in thefoo/**hierarchy. And that's all folks :) I've been using this strategy for years on my own apps with great success so far. It allows to very easily invalidate related contents.A working implementation is provided for the Redis and Filesystem adapters.
I suggest looking at the test case to see how it can be used.
Further work could be done later to define internal interfaces that would allow having a separate storage for cached items and cache tags (php-cache already has such similar thing). But this is not required to get this very PR included IMO.
WDYT?