Problem/Motivation

invalidateAll() has been proposed to be deprecated and removed from core #3498947: Deprecate CacheBackendInterface::invalidateAll(), see reasons there.

Redis will only be able to fully remove this once it requires a version of Drupal that has this API fully removed.

Steps to reproduce

Proposed resolution

As an intermediate step, this allows to opt-in to a new behavior that treats invalidateAll() like a deleteAll(), which saves an extra cache tag lookup for each bin.

Remaining tasks

User interface changes

API changes

Data model changes

Issue fork redis-3500680

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:

About issue forks

Comments

berdir created an issue. See original summary.

berdir opened merge request !50

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Status: Active » Needs review

This seems to work quite well, tested quite a bit in combination with a few core performance issues I worked on.

  • berdir committed b30d325f on 8.x-1.x 
    Issue #3500680 by berdir: Allow to remove support for invalidateAll()...
berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Issue summary: View changes
Status: Needs review » Fixed

Merged, also created a change record.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Category: Bug report » Task

Status: Fixed » Closed (fixed)

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

rbrandon’s picture

rbrandon commented

@berdir is there a downside to opting into this? seems like the same data would be returned in both cases but without the cache tag lookup? I wasn't sure if deleteall hit any other data that would not normally be cleared, for example if it hits a cache with a different prefix.