Yes, of course you can submit a PR.
You’ll need to be very careful with using filters, because the object cache boots before even muplugins_loaded is called, so your filter registration might not have run by the time the cache starts.
Calling redis_cache_skip_persistent_cache for each key can be a big performance hit. This would need to be a static check once to only apply the filter when something is registered.
Hi @tillkruess,
Thank you for your swift input.
#1 Load Order
You’ll need to be very careful with using filters, because the object cache boots before even muplugins_loaded is called, so your filter registration might not have run by the time the cache starts.
Yes this makes sense, object-cache.php is loaded very early in the cycle. For this particular use case we have in mind, this wouldn’t be an issue. For background, we’ve written a framework that provides handling of core wp entities via an object orientated interface. e.g:
$post = new Post();
$post->set_title("Hello World");
When our new post’s setter methods are called, we need to run wp_cache_set(..) to ensure the underlying WP_Post object holds the new title. Unless $post->save() is called at some later point, this really shouldn’t be persistently stored however.
#2 Hook Performance
Calling redis_cache_skip_persistent_cache for each key can be a big performance hit. This would need to be a static check once to only apply the filter when something is registered.
Right, I wondered if this might be an objection. Perhaps you wouldn’t mind expanding a little further on this point? In particular, given that WP_Object_Cache already fires various hooks (such as redis_cache_expiration, redis_object_cache_get and redis_object_cache_get_value) on every call – how might adding this hook constitute a big performance hit comparative to the existing hooks?
Thanks again for your time on this Till.
Hi @tillkruess, any further comment or thoughts on this? Thanks.
how might adding this hook constitute a big performance hit comparative to the existing hooks?
Adding another call means another filter run which isn’t necessary.
When our new post’s setter methods are called, we need to run wp_cache_set(..) to ensure the underlying WP_Post object holds the new title. Unless $post->save() is called at some later point, this really shouldn’t be persistently stored however.
Non-persistent groups already exist as a concept and making individual keys non-persistent seems like the wrong approach / architecture.
Even if I’d merger such a filter, what about all the other caching plugins?
