[wp-hackers] transients API and removing stored results

Phillip Lord phillip.lord at newcastle.ac.uk
Thu Mar 3 17:15:23 UTC 2011

Andrew Nacin <wp at andrewnacin.com> writes:
> One, I would cache this to postmeta instead of using transients. They're
> tied to posts, so it works from an implementation perspective. Assuming an
> object cache is leveraged, you're not even hitting the database, but note
> that postmeta is already queried for posts in the loop, so you're not really
> running into performance issues either.

Okay, that's an interesting idea. As Casey points out this has the
disadvantage that identifiers can cross posts, although I have no idea
how common this will be in practice -- the plugin is early stage so we
don't have the data. And if the data has already been pulled from the
database, we are saving and gaining at the same time. 

> In this case, you will need to implement your own expiration, but that's
> pretty simple, and you've already written the framework for most of that.
> Like how we do this in the transient API, just store an expiration time. On
> fetch, check the expiration time. (You could probably even do this on a hook
> if you want to be clever.)

Hmmm. Well, that's possible, but then it's a bit of a pain, and seems to
be duplicating the transients; given that "normal" expiration will be
the deployed form, while "force" expiration (delete the cache) is mostly
a development issue, this seems backward to me. I'd rather let wordpress
APIs handle the normal cases. 

> To clear everything, you can do a wildcard query, or even flush a post such
> as on save. But in this case, you can also flush the postmeta cache for the
> affected posts. (You can't do this efficiently for transients.)

Looking at the implementation, it appears that I could do 


and then load through all of these. This would get me to the kcite
transients which I could then delete. This would break when there is a
cache plugin (which is I guess why they don't allow wildcard deletes
with would solve the problem), but then I'm not going to be caching on a
development system. 

Actually, looking at the transients implementation worries me slightly;
there are several occasions when wp_load_alloptions() gets called; my
use is putting quite a lot of data into this, which is a bit of a worry. 

It's also poking into wp internals a bit more than I would like, but at
last this is only during development. 


More information about the wp-hackers mailing list