[wp-hackers] transients API and removing stored results

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

Casey Bisson <casey.bisson at gmail.com> writes:

> It may add more complexity than you want or need, but have you
> considered creating a custom post type to cache these lookups? It
> would make it relatively easy to delete all posts matching the given
> type, and you can leverage the taxonomy and postmeta tables to store
> detailed info about each reference.

This looks a bit heavy weight to me, although I just don't know for
sure; I'm not a wordpress hacker trying to make it work for science, I'm
a scientist trying to hack wordpress if you see what I mean. I'll
investigate custom post types and see how they look. 

> The easy alternative is to just create a function that deletes all
> options rows where option_name LIKE {$transient_prefix}%, but that
> raises two less easy problems: it doesn't delete the relevant cache
> keys cases where memcache or some other persistent cache is in use,
> and it's probably not safe to assume that all those matched rows are
> in fact transients.

Looking internally, the transients API does enforce "__transient__" as a
slug, and I am enforcing "kcite" as the next five characters. I guess
this is as a reasonable degree of specificity; in the first instance,
for sure, it seems the way to go. 

The persistent cache shouldn't be a problem because forcing expiration
is mostly a development issue. 


More information about the wp-hackers mailing list