WordPress.org

Make WordPress Core

Opened 12 years ago

Last modified 5 months ago

#4476 reopened enhancement

Delete Cache by Group

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

Description

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 12 years ago.

Download all attachments as: .zip

Change History (18)

@filosofo
12 years ago

#1 @filosofo
12 years ago

  • Keywords has-patch added

#2 @ryan
12 years ago

  • Milestone changed from 2.3 to 2.4 (next)

#3 @ryan
12 years ago

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

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

#4 @Nazgul
12 years ago

  • Milestone 2.5 deleted

#5 @sc0ttkclark
7 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
7 years ago

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

#7 @scribu
7 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
7 years ago

  • Keywords close added; dev-feedback removed

#9 @sc0ttkclark
7 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
7 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
7 years ago

  • Milestone Awaiting Review deleted

#12 follow-up: @Ste_95
2 years 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.

https://www.tollmanz.com/invalidation-schemes/

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 2 years ago by Ste_95 (previous) (diff)

#13 @Ste_95
2 years ago

Any news on thys guy? @SergeyBiryukov tagging you as you seem to be the only one with recent activity.

#14 in reply to: ↑ 12 @dd32
2 years ago

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

Replying to Ste_95:

Why hasn't this received any more attention? I still think it's relevant.

This was made irrelevant when WordPress removed persistent caching.
File-based Persistent caching was removed in WordPress 2.5 and switched to a non-persistent per-request cache instead, which removed the need to clear the cache like this.

The cache is designed to be replaced by a persistent in-memory cache such as memcache, redis, or any other number of cache backends. These do not generally allow deletion of an entire cache group, adding support to WordPress for it is therefor not exactly useful.

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?

While we could enable this, it would cause your code to be not-very-portable, as soon as you used it on any site that had an external Object Caching dropin enabled, you'd see the code completely fail to operate as expected.

The invalidation method posted by scribu is good with memcached, but not if cached data goes to the database as a transient:

Transients are completely different to the wp_cache_*() functions, although transients do utilise them if an external cache is in use.
If you've got wp_cache_*() setup through a drop-in to use transients, then that's probably a bad move - it's really not designed to be used like that, and you'd be better off with that disabled in many scenario's I would assume.

You may want to look at how you're using transients if that's the case, and reconsider their usage. It sounds like you're using them in a way they weren't designed, or something similar. #20316 may interest you.

I'm re-closing this ticket as wontfix, you may comment here while the ticket is closed, but for the reasons outlined above, we won't be adding a Delete Cache by Group functionality right now, and probably not anytime soon.

#15 @dhilditch
7 months ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Instead of adding 'delete by group', to achieve the same desired functionality - namely, the ability to 'delete' chunks from the cache without wiping the entire cache - how about this approach:

  1. Add an extra parameter to wp_cache_get and wp_cache_set called 'namespace'
  2. When the namespace parameter exists, use the code given by @scribu to append a number to the $key param
  3. Add a new function wp_cache_clear_namespace with the namespace parameter - this function increments the namespace number so - in-effect - all items for this namespace are 'deleted'.

Otherwise EVERY developer has to keep coding their own versions of the code from @scribu both for getting items from the cache and for setting items in the cache, and most won't bother and instead will just flush the entire cache when their settings pages change which is entirely unnecessary and detrimental to the performance of large websites.

#16 @dougal
5 months ago

I have a current use-case where deleting by group would be useful -- a long-running report job where I want to track whether I've already processed certain items in the current queue run, then delete the cached hits after the report is done.

But yeah, since not all external caching mechanisms provide a mechanism for that functionality, and the dropins would have to be updated with the new method, I can see why it's wontfix. :-/

#17 @SergeyBiryukov
5 months ago

  • Milestone set to Awaiting Review
Note: See TracTickets for help on using tickets.