Deprecate CacheBackendInterface::invalidateAll()

Created a basic merge request, will need an update with the change record if others agree.

Can we add a CR for the deprecations and update the messages to use that link vs the issue. Since there is a replacement I'm a big fan of before/after snippets

I tend to start off without to get early feedback. But I'm also aware that helps with explaining the reason, created one now.

Per slack this is fine to remove.

Just fyi wasn't against it or anything just didn't think I could make the call around it but @catch was kind enough to approve.

Verified the CR reads well, thanks for the before/after snippets.

Don't see anything else to review.

I agree with #6 that the CR is quite readable. But perhaps like Hayden would perfectly understand Mozart's explanation of a passage, the CR is a IMO a little hard to grasp for an average musician.

I have edited it and tried to put it in terms that I understand which has the advantage of showing what I am not grasping. Using the supermarket shelf analogy, I am unsure about what happens when the item is deleted (incinerated). It seems that with Redis etc a label is placed on the shelf stating 'this item has been incinerated'? Not sure about Drupal standard caching, though.

I'm not sure how detailed the change record needs to explain invalidate vs delete. This doesn't change the concept of invalidation or remove it, it only removes the ability to invalidate a whole bin. deleteAll() in redis has exactly the same problem as invalidateAll(), it also doesn't actually delete anything and just sets a timestamp. With redis, deleteAll() doesn't mean that cache items cease to exist.

That said, I wrote a long blog post about the background and details around some of my recent performance improvements: https://www.md-systems.ch/en/blog/2025-01-26/redis-startup-performance-i...

@berdir Ah, interesting it's even more complicated than i thought. Perhaps including the link would help.

it only removes the ability to invalidate a whole bin

That seems a really important point at least for my personal understanding.

deleteAll() in redis has exactly the same problem as invalidateAll(), it also doesn't actually delete anything and just sets a timestamp

Okay but this issue does not make any difference to that Redis problem? It is a Redis problem that is much harder to deal with? Even though the nature of the problem is very similar.

The difference is that deleteAll() is needed. We need a way to completely delete all entries in a bin. What we IMHO don't need is two different ways of doing that. As I wrote in my blog post, you should only use invalidate* methods when you have a specific use case and might want to later on fetch invalidated items again. For anything else, use delete*() methods.

Then redis only needs to handle one all method and not two that vary and therefore require a different implementation and different check.

Needs a rebase.

gitlab MR rebase was enough.

Committed/pushed to 11.x, thanks!

catch → closed merge request !10876

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