The node_list cache tag is very generic. We've already introduce a list cache tag per bundle #2145751: Introduce ENTITY_TYPE_list:BUNDLE cache tag and add it to single bundle listing and are looking at how to use it - #3055371: Use new cache tag ENTITY_TYPE_list:BUNDLE in Views to improve cache hit rate. But there is another issue. Every time an unpublished node is edited or a draft created the list cache tags are invalidated. This means that an editor doing small edits to an article whilst preparing an article is behaving like a cache buster for any views that list nodes - for example taxonomy listing, recent content and the frontpage view. Since the node is unpublished none of these changes will cause any real changes.
Introduce an published list cache tag and work together with #3055371: Use new cache tag ENTITY_TYPE_list:BUNDLE in Views to improve cache hit rate to work out how views filters can alter the list cache tags of a view.
Comments
Comment #2
alexpottComment #3
alexpottComment #4
geek-merlinGreat question at a great time.
I stated another instance of this in comments #3055371-24: Use new cache tag ENTITY_TYPE_list:BUNDLE in Views to improve cache hit rate, #3055371-38: Use new cache tag ENTITY_TYPE_list:BUNDLE in Views to improve cache hit rate, #3055371-43: Use new cache tag ENTITY_TYPE_list:BUNDLE in Views to improve cache hit rate, but guess it was not groked in the debate.
How i understand the context of this:
We want cache tags with a granularity finer than the list tag, for pre-filtered views lists (such that creating or updating an entity outside that list will not invalidate the view).
We now HAVE the ENTITY_TYPE_list:BUNDLE cache tags, and there are good reasons to add ENTITY_TYPE_list:published cache tag.
Note that this clashes if a bundle is named "published".
So we arrive at the question: which of the potentially infinite list of filtered views do we support in core?
- Maybe we leave all to contrib.
- Maybe we find a way to name cache tags after their JsonApi query string and let sitebuilders configure which are handled.
(So in this case something like ENTITY_TYPE_list:_jsonapi:published=1
So this new use case raises the question: How do we allocate the cache tags namespace?
(But from your comment in the other issue it's clear to me that i'm not smarter than you, and you had that question in mind ;-).
Comment #7
les limHow would this work, in theory? Say I make a minor edit to an unpublished node, leaving it unpublished. Which cache tags would we then invalidate?
Comment #9
joachim commentedRather than adding new subdivisions of list caching one by one, I wonder whether we could add something generic: see #3279764: Segmented ENTITY_TYPE_list:* cache tags.