[Cache] Add hierarchical invalidation with ContextAwareAdapterInterface #19521
Conversation
dfc5f6a to
96b54e7
Compare
|
For reference, the intent of this PR is to provide a basic block that could allow building something like Drupal Contexts: |
87b6c58 to
e789c2a
Compare
f4740f2 to
2eb0b09
Compare
| return $this->namespace.$key; | ||
| } | ||
| if (strlen($id = $this->namespace.$key) > $this->maxIdLength) { | ||
| $id = $this->namespace.substr(str_replace('/', '-', base64_encode(md5($key, true))), 0, -2); |
There was a problem hiding this comment.
Namespace prefix excluded, this produces a string of length 22 (thus the 22/23 in the code)
(the last two cut chars are padding =)
4e02558 to
ec4957b
Compare
…s-grekas) This PR was merged into the 3.1 branch. Discussion ---------- [Cache] Use SCAN instead of KEYS with Redis >= 2.8 | Q | A | ------------- | --- | Branch? | 3.1 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - With #19521 coming, clearing cache keys by prefix is going to be used a lot more often. Time to fix Redis cache clearing. Commits ------- aadeb11 [Cache] Use SCAN instead of KEYS with Redis >= 2.8
5fa8d1f to
024ea79
Compare
024ea79 to
b847b3e
Compare
|
@andrerom or anyone else, any comment here? |
|
So this can for instance be used by HttpCache so it can handle very by logic right? |
|
Yes for sure. https://www.drupal.org/developing/api/8/cache/contexts is a real use case of this feat. Maybe one should first read this page then help me find the right words to explain the feat. ? :) |
|
well I looked at that page, and couldn't help but think most of these use cases (incl Http Cache) could be solved by reflecting context in key, as invalidation is done with tags it won't complicate invalidation, and lookup will need to know the context of what they are looking for anyway. But I'm probably overlooking something. |
true, and this feat. is exactly here for decoupling this: context computation and keys. |
b847b3e to
b6b5628
Compare
|
Vocabulary changed: the interface is now called |
|
Any comment here? Any vote @symfony/deciders? |
|
So, thinking a bit more about this: should calling deleteItem on a parent also clear the item recursively? Looks like it could be useful. Then what about the other psr6 methods? Dunno. Which means this isn't ready :) |
…ant using hashing (nicolas-grekas) This PR was merged into the 3.2-dev branch. Discussion ---------- [Cache] Handle arbitrary key length when the backend cant using hashing | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - Saving some bits from #19521 :) Already awaited by PdoAdapter which defines the property. Commits ------- 11f448f [Cache] Handle arbitrary key length when the backend cant using hashing
|
The reason why there was confusion is that you need a 2-step cache_get() process - or a cache collector like 'Vary' if you want to use that. It gets very useful once you have a sub-item use contexts that are not known to the parent. It basically solves the problem for complex sub-items, which the parent can't query for its contexts and which even might not know its contexts until computation time. |
This PR adds a public interface to do hierachical invalidation. By using the new
withContext()method, one is able to create a contextualized set of cache keys. Invalidating is as easy as changing the context identifier provided as argument.Contexts can be chained to create subcontexts inside contexts.
All subcontexts share the same adapter implementation + connection state.
Clearing a parent clears all subcontexts.
This feature is already implemented by e.g. Drupal 8, and it plays nice with tags: all forks share the same tags space.