[wp-trac] [WordPress Trac] #18244: Add autoload flag to update_option

[WordPress Trac]

#18244: Add autoload flag to update_option
-------------------------+------------------------------
 Reporter:  wpdavis      |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |
-------------------------+------------------------------

Comment (by devesine):

 An essentially equivalent issue, #5702, was closed ("Most options SHOULD
 be autoloaded.") some years ago, but it has been my experience that there
 is fairly widespread use of the Options API to store arbitrary persistent
 data.

 That data is not necessarily relevant to every page request, and there are
 definite downsides to having too many autoload options.  We have in
 production a database with 60,000 rows in the options table and 1,200
 autoload="yes" options; trimming the autoload options down to around 200
 shaved off a quarter of a second from page generation time.  We also
 encountered a database with 25,000 rows in the options table of which
 24,000 (!) were autoload="yes", and it was generating pages in 10-15
 seconds.  Trimming that down to roughly 500 autoloaded options brought
 page generation down to 3-5 seconds.  (Obviously there are other
 performance questions in play as well.)

 I don't know what the right solution here is, but I would start the
 discussion by proposing two things:

 1. Add a new parameter to update_option.  This could either be
 `$autoload_if_creating`, to be passed to add_option but not to the update
 itself, or `$autoload`, to be passed to both add_option and the update if
 it is not NULL.  This wouldn't do anything about existing code, but it
 would allow more straightforward use of the options API for its apparently
 current "generic data store" usage in the future.

 2. Make update_option default to create non-autoloading options if they
 don't exist.  Plugins that use the options API as originally envisioned -
 add_option during activation, update_option thereafter - would be entirely
 unaffected.  Plugins that use the options API as a generic persistent data
 store would generally see a benefit, by not expanding the autoloaded
 options with things that are used infrequently.  The only downside would
 be plugins that expect the update_option functionality to create
 autoloading options - but I suspect the number of developers who are aware
 of the distinction is pretty tiny compared to the number using
 update_option.

 Another path forward might be to make a new interface to the options
 table, specifically for generic, persistent, intermittently-used data
 storage (as opposed to non-expiring transients, which are generic, non-
 persistent, and autoloaded, or expiring transients, which are generic,
 non-persistent, and non-autoloaded).

 (Or maybe I'm entirely missing an API intended for that use that already
 exists?)

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