WordPress.org

Make WordPress Core

Opened 12 years ago

Closed 9 years ago

#11405 closed enhancement (wontfix)

add wp_cache_enable()/wp_cache_disable() methods

Reported by: Denis-de-Bernardy Owned by: ryan
Milestone: Priority: normal
Severity: normal Version: 2.9
Component: Cache API Keywords: has-patch
Focuses: Cc:

Description

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

Attachments (1)

11405.diff (654 bytes) - added by Denis-de-Bernardy 12 years ago.

Download all attachments as: .zip

Change History (13)

#1 @ryan
12 years ago

See also #5389

#2 follow-up: @westi
12 years ago

  • Cc westi added
  • Milestone changed from 2.9 to 3.0

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.

#3 @Denis-de-Bernardy
12 years ago

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.

#4 @Denis-de-Bernardy
12 years ago

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.

#5 in reply to: ↑ 2 @hakre
12 years ago

  • Keywords has-patch dev-feedback added

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?

#6 @Denis-de-Bernardy
12 years ago

  • Keywords needs-patch added; has-patch dev-feedback removed
  • Milestone changed from 3.0 to Future Release
  • Type changed from defect (bug) to enhancement

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

#7 @Denis-de-Bernardy
12 years ago

  • Keywords has-patch added; needs-patch removed

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

#9 @Denis-de-Bernardy
12 years ago

  • Milestone changed from Future Release to 3.0

#10 @nacin
12 years ago

  • Milestone changed from 3.0 to Future Release

#12 @nacin
9 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.