[wp-hackers] transients API and removing stored results

[Phillip Lord]

Jeremy Clarke <jer at simianuprising.com> writes:

> 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.
>
> 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. 

I wouldn't even need this -- get_all_transients() would be enough. This
would have the advantage that the search matching would be done in PhP
which would abstract over the backend storage capabilities. This is
implementable, as it stands, via get_all_options(). 

Performance would suck in comparison, but this is not a method I would
be calling often in a production website. 

> 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.). 
[snip]
> 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.


The code is there in get_transient() method, and you right, it could be
replicated and extended, even if it would be a bit fragile to future
changes in schema/representation within the schema (transients uses
microsyntax "__transients__" on top of options). 


> 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 ;)


This would more than fulfil my current requirements and would be lovely,
although it's not obvious how to implement it cleanly without schema
extension. The group notion would need to be in the database, or else
more microsyntax would be needed. 

Phil