[wp-trac] [WordPress Trac] #20316: Garbage collect transients

[WordPress Trac]

#20316: Garbage collect transients
----------------------------------------------+------------------
 Reporter:  nacin                             |       Owner:
     Type:  enhancement                       |      Status:  new
 Priority:  normal                            |   Milestone:  3.7
Component:  Database                          |     Version:
 Severity:  normal                            |  Resolution:
 Keywords:  dev-feedback has-patch 3.7-early  |
----------------------------------------------+------------------

Comment (by DavidAnderson):

 I think everyone on this ticket understands the intended purpose of
 transients - to store data that is capable of being regenerated.

 The issue I'm seeing is that because of the state of the documentation in
 Codex, many coders have come to use them another way. If you read through
 http://codex.wordpress.org/Transients_API, then you can easily come away
 with the understanding that the expiration time is the *maximum*. The fact
 that transients can (and should be expected to) expire at *any* time is
 implicit/in the background, and can easily be missed. If you read the
 "Overview" section through, trying to read it as if it spread first one
 view, then the other, you'll see what I mean. dd32 says that people are
 "abusing" the transients API. That's correct - but I contend that the
 documentation has led, and is still leading, people into that.

 Note that I'm not saying that WP should change it's intended approach to
 transients. What I am suggesting is that:

 a) The documentation needs changing to make the real intention clear. A
 second aspect of this is that the documentation for the Options API also
 needs clarifying. As dd32 says, people *should* be using the Options API
 for this. But again, this is easy to miss. If you read the summary of the
 Options API, you'll get the idea that it is for... options. The fact that
 it's actually the intended API for all kinds of stored data (including
 'transient' data, where the transience is intended to be effected with a
 *maximum* expire time, and that the Transients API should *not* be used in
 that case), is something rather subtle - it is likely that only a seasoned
 WP developer will realise this, after some time and experience.

 b) In the light of that, I am suggesting that WP should handle the change
 in the patch applied in this bug more gradually. The concern has been
 expressed that the handling of transients during a DB upgrade should be
 'clean and fast' - preferably in one SQL command. In fact, as see in David
 Artiss's plugin, it is possible to clean expired transients (only) whilst
 using only one SQL command; here it is:


 {{{
 DELETE
                                         a, b
                                 FROM
                                         {$wpdb->options} a,
 {$wpdb->options} b
                                 WHERE
                                         a.option_name LIKE
 '_site_transient_%' AND
                                         a.option_name NOT LIKE
 '_site_transient_timeout_%' AND
                                         b.option_name = CONCAT(
 '_site_transient_timeout_',
                                                 SUBSTRING(
                                                         a.option_name,
 CHAR_LENGTH('_site_transient_') + 1
                                                 )
                                         )
                                 AND b.option_value < UNIX_TIMESTAMP()
 }}}

 Thus, it seems to me that the main reason why people want to enforce
 "delete all transients" does not exist: it can already be achieved another
 way, without adding complexity. Look at the pros and cons on either side:
 yes, 'delete all transients' is in keeping with the true purpose of the
 Transients API, and will force programmers to learn that fact very
 quickly. However, I contend that it's too quick. Developers will
 realistically only wake up to this once the strange and hard-to-reproduce
 bug reports come in for their already-existing applications. Given that
 the current version of WP doesn't delete any expired transients (unless
 they are accessed), switching suddenly to force-deleting all transients in
 3.7 instead of just the expired ones will give significant real-world pain
 for little gain. Much better to just delete the expired ones, whilst
 educating programmers about the intended purpose of the transients API
 over a period of time, before switching to deleting them all at a later
 stage once developers have had time to adapt (if it's felt that it is
 beneficial to enforce the purpose of the API). That way, you get all the
 gain without the pain.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/20316#comment:49>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software