Irrelevant caches have been cleared during EntitySubqueue save

Hello,

We are having an issue with that cache tag, entity_field_info .
We have a website where each page is built by the list of multiple entity_subqueues with nodes list.
If we change the order in one sub-queue, it purges the cache for every entity in all pages, as each entity is tagged with that cache tag. That leads us to load everything from DB on each change in any sub-queue.

From my point of view, the EntityQueue entity type only has settings and doesn't have fields so there is no necessary need for the entity_field_info cache tag.

Here's the reasoning:

• Purpose of entity_field_info: This cache tag tracks information about entity fields. If an entity has no fields, there's technically nothing to cache regarding field definitions.
• Cache invalidation: The entity_field_info tag invalidates caches when field definitions change. With no fields, changes to settings wouldn't affect field definitions.

I would like to hear what is your opinion about this and can we maybe merge the patch?

I went through all the old caching issues, and here's a quick summary:

#2645060: Newly added entity queues are not getting listed under relationship in views →

Tested this one by removing the views_data cache tag, and when adding a new queue it shows up correctly in the relationship configuration screen.

#2634154: items_target_id in entity_subqueue__items should not be an int →

In this one I added the entity_field_info cache tag to the EntitQueue entity type.. can't really remember the reason so I think it's fine to remove it.

#2686623: Empty views cache when queue is updated →

Here is where I made subqueues invalidate the parent queue's cache tags. Tested this as well and it's no longer needed because views that have an entity reference relationship now include the entity_subqueue_list cache tag (see \Drupal\views\Plugin\views\cache\CachePluginBase::getCacheTags()), which means cache will be invalidated when a subqueue is updated by editing its items.

In short.. Drupal core has gotten way better at cache invalidation in the past 8 years, so all our hacks are no longer needed :)

The last submitted patch, 6: 3221428-6.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

A test view had to be updated.

Committed to 8.x-1.x!

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