Only the current thing knows *what* it is and *how* to generate a unique key. Cache keys, on the other hand, don't need to be bubbled up - they couldn't be, it'd be nonsensical.Cache tags need to be bubbled up, because they indicate "what the contained things are", so if a parent gets cached, then it must be tagged with the union of all nested cache tags.Overall, it looks like it might be better to not merge "cache granularity" with "cache keys"? When caching, "cache granularity" should indeed be converted to "cache keys". Wim Leers, in #2158003-30: Remove Block Cache API in favor of blocks returning #cache with cache tags, a year earlier (while reading, substitute "granularities" for "contexts"): Keeping cache granularities, having them affect cache keys & cache tags Just food for thought and not in this issue for sure. This is just an idea I had when reading #21, but thinking about this some more, maybe we should add a cache tag whenever we add a cache context, so that its no longer the one adding the cache contexts to also add the cache tags, which might not even be known at that time or double the logic. Remaining tasksĪdded AccessResult::cachePerPermissions() Original report by Wim LeersįabianX, in #2329101-23: CacheableInterface only has a getCacheKeys() method, no getCacheContexts(), leads to awkward implementations: Use this new cache context whenever varying something by permissions. Proposed resolutionĪdd user.permissions cache context, which uses the existing PermissionsHash(Interface). That means that if the set of permissions assigned to a role changes, that anything that is cached per role is not invalidated.
But that's an indirect representation of the permissions. When caching something per role, we're usually doing that because of checking permissions.
0 kommentar(er)
