Skip to:
Content

bbPress.org

Opened 5 years ago

Last modified 2 years ago

#2664 new enhancement

Repair functions don't reset the post cache

Reported by: jacklenox Owned by:
Milestone: 2.8 Priority: high
Severity: normal Version:
Component: Tools Keywords: needs-patch
Cc:

Description

After a considerable amount of head scratching, I've realised that the repair functions do not reset the post cache, which I think they ideally should when making direct changes to the database via $wpdb->query.

In my particular situation this was necessary for recalculating reply counts as the site that I'm working on is already live (we have migrated data from a bbPress 1 installation).

Alternatively, perhaps the repair functions could be rewritten to work with loops and update_post_meta() etc. This would make them significantly slower but at the same time safer and less memory intensive.

For reference, I'm referring to the repair functions located in: includes/admin/tools.php

Change History (3)

#1 @johnjamesjacoby
5 years ago

  • Component changed from General to Tools
  • Milestone changed from Awaiting Review to 2.7
  • Priority changed from normal to high

Good catch. On large and active forums, going nuclear on the cache has it's own consequences, but I think purging caches is still the lesser of these two evils.

Moving to 2.7 to investigate this more.

#2 @johnjamesjacoby
5 years ago

  • Milestone changed from 2.7 to 2.8

Bumping all 2.7 to 2.8 milestone.

#3 @johnjamesjacoby
2 years ago

  • Keywords needs-patch added
  • Type changed from defect to enhancement

The problem with looping & using the procedural functions is two-fold – time and memory. It's slow because of the number of function & method references, and it uses a lot of memory because those references add up exponentially with each call. To avoid both scenarios, we need to basically avoid them both by doing big queries, and then big cache invalidations.

For most cases, it's probably easier (and less error prone) to just flush the entire cache. Otherwise the rest is high that something gets missed mid-job that cascades into other jobs or data.

The repair & upgrade tools would need to work in the following way, with relative accuracy and low latency:

  • Suspend cache invalidation & writes
  • Do all the heavy lifting, and keep track of the objects & IDs that are touched
  • Restore cache invalidation
  • Invalidate all of the caches
  • Restore cache writes

I'm not sure if we can control both directions, so this will require more digging.

Note: See TracTickets for help on using tickets.