[wp-hackers] transients API and removing stored results

[Jeremy Clarke]

On Thu, Mar 3, 2011 at 7:45 AM, Phillip Lord
<phillip.lord at newcastle.ac.uk>wrote:

>
> So, my question, is it possible to delete_transients based on a
> wildcard? I could do this with a database query, but as the codex says
> "don't assume your transients are in the database". I would like to be
> able to add a "clear cache" function to the admin page for this plugin.
>
>
First, I think that though the postmeta/cpt ideas aren't bad, you are right
to think that transients are the way to go. You have complex but
well-considered needs and other than the clearing element transients are a
perfect fit.

To me this situation implies two ideas.

One is a *get_transients($search_string)* function that would let you fetch
transients based on a search string. You could then loop through the results
and delete each one. Alternately you could just have *
delete_transients($search_string)*, but this seems unnecessarily specific
and wouldn't be useful for as many different things (with the get_* version
you could do the same as the delete_* version with one line of code:
*foreach(get_transients(XXX))
delete_transient(); *)

That option is desirable because even if it wasn't in core, you could write
it yourself and it would be fairly easy to maintain. AFAIK transients are
only ever stored in two places: *wp_options* and the *'object
cache'*(memcache, apc, xcache etc.). In your/core get_transients()
function you
could check both locations and clear them as necessary. The object cache
offers a generalized API that abstracts away the complexities of the
different storage engines, so it probably wouldn't be that hard to set it
up. I bet there's even a function to check if a persistent cache is
operating, in which case you woudl only have to run one version of the
deleting code depending on whether the site is using a persistent object
cache or wp_options. Obviously the code could stop working in the future and
you'd have to maintain it yourself, but it would probably not break very
often.

Another option, really only available via core, would be to add a $group
parameter to the transients functions, then add a *delete_transients($group)
* function that could clear them en-masse. This would make the transients
API match the object cache API more closely and ultimately I think it's a
really logical way to improve the transients API. Even without a $group
parameter, almost all transients are going to fall into some kind of
grouping and it's not hard to think of other uses of get_transients($group)
and delete_transients($group). In fact the more I consider it the more it
feels like a serious omission (i'm second guessing some of my own 'cache
clearing' code and whether it adequately clears transients ;)

-- 
Jeremy Clarke • jeremyclarke.org
Code and Design • globalvoicesonline.org