[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