Repair functions don't reset the post cache

[jacklenox]

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

[johnjamesjacoby]

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.

[johnjamesjacoby]

Bumping all 2.7 to 2.8 milestone.

[johnjamesjacoby]

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.