Make WordPress Core

Opened 10 years ago

Last modified 12 days ago

#4476 reopened enhancement

Delete Cache by Group

Reported by: filosofo Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.2
Component: Cache API Keywords: has-patch close
Focuses: Cc:


Currently, you have to specify the id of the cached item in order to delete it via wp_cache_delete, or you have to flush the entire cache via wp_cache_flush.

Instead, it would be helpful if one were able to delete an entire group without having to flush all of the cache.

For example, term-related plugins could expect their particular caches to be deleted whenever changes to any terms were made, instead of having to use callbacks for every term-related action.

Attachments (1)

cache.php.diff (1.1 KB) - added by filosofo 10 years ago.

Download all attachments as: .zip

Change History (13)

10 years ago

#1 @filosofo
10 years ago

  • Keywords has-patch added

#2 @ryan
10 years ago

  • Milestone changed from 2.3 to 2.4 (next)

#3 @ryan
9 years ago

  • Resolution set to invalid
  • Status changed from new to closed

Cache has been gutted, so this is no longer relevant.

#4 @Nazgul
9 years ago

  • Milestone 2.5 deleted

#5 @sc0ttkclark
5 years ago

  • Cc lol@… added
  • Keywords dev-feedback added
  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version set to 2.2

Looks like the reason this was closed is no longer the case. What's the plan here? I want to delete all items for a specific group.

For now, I'll just work with the object itself, but there's a definite need for a function like wp_cache_delete_group or the patch as attached.

#6 @SergeyBiryukov
5 years ago

  • Component changed from Administration to Cache
  • Keywords cache wp_cache_delete removed
  • Milestone set to Awaiting Review

#7 @scribu
5 years ago

The reason this is not part of the API is that most persistent caching backend such as memcache don't support deleting an entire group.

What's done instead is increment the group prefix and let memcache's garbage collector remove the items from the old group, which are never accessed anymore.

#8 @scribu
5 years ago

  • Keywords close added; dev-feedback removed

#9 @sc0ttkclark
5 years ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

Okay, sorry for my n00bness as I'm diving deeper into WP caching than ever before, but how would I increment the group prefix? Feel free to reply with a *slap*

#10 @scribu
5 years ago

Actually, you don't change the prefix of the group, but add a prefix to each individual key:

$ns_key = wp_cache_get( 'foo_namespace_key' );

// if not set, initialize it
if ( $ns_key === false )
  wp_cache_set( 'foo_namespace_key', 1 );

$my_key = "foo_".$ns_key."_12345";
$my_value = wp_cache_get( $my_key, 'some_group' );

To clear the namespace do:

wp_cache_incr( 'foo_namespace_key' );

Source: https://groups.google.com/forum/?fromgroups#!topic/memcached/Izov0cFjBXI

#11 @scribu
5 years ago

  • Milestone Awaiting Review deleted

#12 @Ste_95
12 days ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Why hasn't this received any more attention? I still think it's relevant. The invalidation method posted by @scribu is good with memcached, but not if cached data goes to the database as a transient:

It is important to note that if you are not careful about how you are using this design pattern, you could accidentally consume all of your cache storage space. This strategy relies on changing the key that is used to access the cached object; it never removes the previously cached versions of the objects. It leaves it in the cache's storage. If your caching backend relies on a caching technology that does not automatically handle cache evictions, you may completely fill that storage. I tend to work with memcached on large projects that need efficient caching. Memcached implements an aggressive (sometimes way too aggressive) eviction policy whereby cached objects are frequently removed from cache. You can change the keys for the cached objects and the older objects will be removed from the cache, making room for newer versions of the objects. As such, the incrementor invalidation strategy is an effective tool in a memcached environment.


Why not implement the patch from @filosofo? Or at least provide a method to access the $cache class var, so that we could iterate through the category array and manually delete each key?

Last edited 12 days ago by Ste_95 (previous) (diff)
Note: See TracTickets for help on using tickets.