add wp_cache_enable()/wp_cache_disable() methods

[Denis-de-Bernardy]

In WP, they'd just return true. This would be for use with a memcached backend.

Related tickets:

​http://backpress.automattic.com/ticket/15

​http://backpress.automattic.com/ticket/16

[ryan]

See also #5389

[westi]

I don't think we should rush this into 2.9 at the last minute so I am going to set a 3.0 milestone for this.

I am not sure why you need this for your plugin - maybe you could write up a simple summary of the issue you are having and the reason why this is the best solution to resolve the issue.

Without that it is very hard to review the change requested here.

[Denis-de-Bernardy]

oh the issue is about limiting the amount of memory consumed while generating a sitemap xml file.

basically, I query each and every last post, for only one purpose: to generate a permalink. not all fields are needed for this. in particular the excerpt and content, which are expensive to retrieve. so I add a filter to the posts fields, in order to stick to those that could be needed.

I then update_post_cache() the mess so that get_permalink() doesn't cause tremendous numbers of queries, since that also tends to be resource intensive. and this is the part where I end up with issues: any post that isn't already in memcached ends up with junk.

In the update I'll be releasing, I'm fixing this by marking the posts and postmeta buckets as temporary, and it's working fine as far as I can tell. so safely close as wontfix if you think it's not needed.

[Denis-de-Bernardy]

I've been experimenting with a slightly different approach, when dealing with the flush() method. The bug I was having was the following:

When I had my plugin disable the object cache from the admin screen, I would flush. But after calling flush -- before the end of the page -- memcached would re-cache alloptions. When I'd re-enable the object cache, the object cache's file would be around in WP_CONTENT_DIR but it would show (as in the option) as disabled on the admin screen.

What I ended up doing was to add a flush variable in the object cache class. When enabled, it would disable add(), set() and replace() until the end of the page, while keeping delete() functional.

[hakre]

Replying to westi:

I don't think we should rush this into 2.9 at the last minute so I am going to set a 3.0 milestone for this. ...

I think your questions have been answered by the following comments onto yours. Can you please review again and post your current status on this ticket? OK to commit now to give it a go?

[Denis-de-Bernardy]

After having tested various approaches, I'm inclined to think the following is better:

• disable() should mark non-global groups as non-persistent except for wp_cache_delete()
• enable() should flush the local cache and restores persistence

[Denis-de-Bernardy]

has-patch for core, but definitely needs a better patch for backpress

[Denis-de-Bernardy]

seems this gets used somewhere in MU, too:

​http://core.trac.wordpress.org/browser/trunk/wp-activate.php#L10

[Denis-de-Bernardy]

See also #5389

[nacin]

No traction on this. We have the ability to suspend both invalidation and addition via the API, which is often sufficient.