[wp-trac] [WordPress Trac] #14080: Needless wp_cache_delete() inside set_theme_mod()

WordPress Trac wp-trac at lists.automattic.com
Tue Nov 16 19:11:53 UTC 2010


#14080: Needless wp_cache_delete() inside set_theme_mod()
--------------------------+-------------------------------------------------
 Reporter:  shidouhikari  |        Owner:        
     Type:  defect (bug)  |       Status:  closed
 Priority:  normal        |    Milestone:  3.1   
Component:  Cache         |      Version:        
 Severity:  normal        |   Resolution:  fixed 
 Keywords:                |  
--------------------------+-------------------------------------------------

Comment(by shidouhikari):

 Thanks nacin.

 gazouteast, I understand your agony, I also have some wp_options rows that
 are bloating database and I don't have the time to hunt them.

 But it's not the case here, hold your anger. Where did you see that cache
 is stored in database? Normally, cache is temporary stored in RAM during a
 page load and lost when the page finished loading. There are some plugins
 that persistently stores cache in HD and even in RAM servers, but even so
 cache is used to avoid database queries.

 When update_option() is called it updates the cache, and next time
 get_option() is called and data isn't in cache it's added there, so
 there's no reason to have a wp_delete_cache() after a update_option().

 The best solution for our database bloating issue is everybody be
 responsible for each option added, handle its deletion when adequate, and
 provide users the possibility of deleting them before uninstalling a
 plugin/theme/widget while not deleting them during a simple deactivation.

 My plugins for exemple have an uninstall form that lists EVERY database
 presence and easily deletes EVERYTHING when admin requires.

 If you want a core feature to delete old options, please develop it. The
 problem is that options are meant to presist and today there's no feature
 to bind an option to the code that added it, so we can't easily know if an
 option that wasn't edited for long time (we can't even know when it was
 last edited) can be deleted or if it's still being used now and then and
 just don't need to be edited.

 Maybe you are trying to talk about transient data. Those one I agree that
 may bloat database if created and never queried again. But in this case,
 just install a persistent cache plugin and they will stop being stored in
 database (and you'll still need to manually delete old ones that were
 created before the plugin was installed).

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


More information about the wp-trac mailing list