Allow non-intrinsic (implementation-dependent) cache context services to specify their parents via DynamicParentContextInterface::getParents()

Created on 17 March 2015, almost 10 years ago

Updated 7 November 2023, about 1 year ago

Quoting @effulgentsia in #2428703: Add a 'user.permissions' cache context (was: "Should cache contexts be able to associate a cache tag?") → :

How about this to address #74: we embed the hierarchy in the context name / service ID only when that hierarchy is intrinsic to the meaning of the context, not merely an implementation choice.

[…]

In a followup, I think we can add a service tag to convey an implementation-driven parent relationship. For example:
  cache_context.pagers:
   ...
    tags:
      - { name: cache.context, parent: cache_context.url.query_args:page }
  cache_context.route:
    ...
    tags:
      - { name: cache.context, parent: cache_context.url }
And thereby allow CacheContexts::optimizeTokens() to optimize for implementations where pagers are solely determined by a single URL query argument and routing is done exclusively by URL.

📌 Task

Status

Needs work

Version

11.0 🔥

Component

Cache →

Last updated 2 days ago

Maintained by
🇬🇧United Kingdom @catch
🇧🇪Belgium @kristiaanvandeneynde

Created by

🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

Live updates comments and jobs are added and updated live.

D8 cacheability

API addition
Enhances an existing API or introduces a new subsystem. Depending on the size and impact, possibly backportable to earlier major versions.

Needs issue summary update
Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

needs profiling
It may affect performance, and thus requires in-depth technical reviews and profiling.

Incomplete comments

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment about 1 year ago →
🇧🇪Belgium kristiaanvandeneynde Antwerp, Belgium
Following up on #43: I now think #2749865-52: Rename the 'user.permissions' context to 'user.roles.permissions', to ensure correct cache context optimization → can be closed because of the comment I linked. Meaning this issue is no longer blocked by it nor by 📌 Add a container parameter that can remove the special behavior of UID#1 Fixed . Having said that, it no longer makes sense to fold either user.roles into user.permissions or vice versa (as explained in the other issue), so we should definitely not add that as an example in the documentation.

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024