Lightweight use of transients

Hi,

when using the transients API, the codex recommends the following usage:

if ( false === ( $value = get_transient( 'value' ) ) ) {
     // this code runs when there is no valid transient set
}

This approach has several downsides:

• Expired transients are messing up the database: They will never be deleted unless an external plugin/function will do it for you.
• Once again: If you want to keep your database clean, you’ll need an additional routine. Most of wordpress users won’t have a look into their database, so their databases will grow and grow.
• Even though you have a routine for cleaning expired transients, the database will have some overhead, which need some OPTIMIZE afterwards
• Even though “option_id” in wp_options is BIGINT: Why create new transients instead of using existing transients?
• If you set no expiration time (for updating after a while), the transient will be autoloaded on every load. So you want to have an expiration.

So I came to the following solution: Instead of letting WordPress decide, which transient is expired or not, I’ll do the check and reuse the existing transient with updated information.
See following code:

// Setting my own timeout
$timeout_transient  = 60 * 5;

$stream = get_transient('streaminglive');

// Fallback if transient was deleted before expiration
if (!is_object($stream)) $stream = new stdClass;

// I'll save the last check into a variable "last_check" (see below) - if the transient is expired based on my timeout, renew it
if (!isset($stream->last_check) || $timeout_stream < (time() - $stream->last_check)) {

// Do whatever you need to get/update your data

$stream->last_check = time();

/*
Attention: 
- The timeout of the transient is much more than my personal timeout
- set_transient checks, if there is a valid transient and will update it instead of creating a new one
*/

set_transient('streaminglive', $stream, 60 * 60);
}

With this approach I’ll workaround all downsides with no disadvantages:

• The amount of queries for get_transient and set_transient stays the same – no more load on database
• The transient won’t expire in the world of WordPress because it will be updated much earlier than the transient is set to expire
• As a result: Existent transients will get reused with updated data instead of messing up the database
• No need for external purging and OPTIMIZE-ing
• As a result less load on database
• option_id won’t get pushed to numbers far from Milky Way
• You can make sure, the transient won’t be autoloaded on each page call because it has a pseudo-expiration

Would be glad to see this approach in many plugins: ressources are almost unlimited, but lightweight usage of ressources is always the better option.

• This topic was modified 8 years, 3 months ago by Steven Stern (sterndata).
• This topic was modified 8 years, 3 months ago by Phil Marx. Reason: Added another list element