Problem/Motivation

The current implementation requires all tags present at the time of invalidation.
In some cases, this leads to a huge build-up of cache tags array.
For example, a node will get assigned with tags for a taxonomy term and all its children.
When a field with this term is updated, the invalidation only invalidates nodes with cache tag that contains respective taxonomy term ID.

Proposed resolution

Allow invalidation strategy to be configurable.
The new strategy will require the presence of only the parent taxonomy term, while the module itself will find parents for any term and, based on that, create tags for invalidation.
Example:
Node 1 has a cache tag for term_0 (0 indicating it is the root parent).
Node 2 has a field with term_3.
Do not assign cache tags: term_2 & term_1 for Node 1.
Instead, when Node 2's field with term_3 changes,during invalidation, find the parents of term_3 and then find nodes that have tags for parents of term_3, so term_2 1 and 0.

Remaining tasks

User interface changes

Maybe add a config form to allow switching between invalidation strategies.

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

petar_basic created an issue. See original summary.

petar_basic’s picture

StatusFileSize
new7.34 KB

Here is a patch that adds a possibility for hierarchical term field invalidation.
It also adds a small config form that enables switching between invalidation strategies.

petar_basic’s picture

StatusFileSize
new7.34 KB

Version with different default strategy.

fago’s picture

Status: Active » Needs work

Thanks for the work on the configuration and the form, but the module is already configured otherwise so we need to follow that. It would be really confusing to have configruation split up with the drupal config system and service parameters, where it already is now - see https://git.drupalcode.org/project/cache_tools/-/blob/8.x-1.x/cache_tool...

So let's move this to a different service parameter notation, e.g. in addition to the current one let's support an optional ":parents" suffix for terms:

with parents:

parameters:
  cache_tools:
    # Entity types and corresponding bundles that apply for invalidation.
    invalidate:
      taxonomy_term:
        - topics:parents

without parents:

parameters:
  cache_tools:
    # Entity types and corresponding bundles that apply for invalidation.
    invalidate:
      taxonomy_term:
        - topics
petar_basic’s picture

StatusFileSize
new3.38 KB

I have rewritten the patch so it uses the existing config now.
Now supporting ":parents" suffix for terms.

fago’s picture

Can we start using issue repositories for this? should make things way more convenient to handle than patches :-)

>+ $ancestors = \Drupal::service('entity_type.manager')->getStorage("taxonomy_term")->loadAllParents($tid);

this must be dependency-injected. You can add drunomics/service-utils as composer dependency and use the trait also.

minor, but nesting the following logic below a foreach multiple times makes the code hard to read/follow/maintain:
+ if ($target_type === 'taxonomy_term' && $invalidate_term_parents) {
+ foreach ($this->taxonomyGetParents($value[$key]) as $parentKey) {
+ $tags[] = $tag_prefix_field . $parentKey;
+ }
+ }
+ else {
+ $tags[] = $tag_prefix_field . $value[$key];
+ }

can we factor this out in a helper method?

petar_basic’s picture

Now using issue repositories. Merge request: https://git.drupalcode.org/project/cache_tools/-/merge_requests/1

- Required service-utils and using entity_type.manager from there
- Moved the required code into a separate method

fago’s picture

Status: Needs work » Reviewed & tested by the community

thx, this looks good now. Let's do some more integration testing and if all is ok, move on with the merge.

  • fago committed b6be07a on 8.x-1.x authored by petar_basic
    Issue #3185895 by petar_basic, fago: Add support for via parent...
fago’s picture

Status: Reviewed & tested by the community » Fixed

testing was all good. and merged! :-)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.