[wp-trac] [WordPress Trac] #64696: Real time collboration effectively disables persistent post caches while anyone edits a post

[WordPress Trac]

#64696: Real time collboration effectively disables persistent post caches while
anyone edits a post
--------------------------------------+--------------------------
 Reporter:  peterwilsoncc             |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Posts, Post Types         |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+--------------------------

Comment (by peterwilsoncc):

 @griffbrad I fundamentally disagree that the `WP_Query` patch is easy to
 reason. Along with many other's, I've spent four or five years working on
 caching within the API. It's complicated and has a large number of edge
 cases.

 I first asked for an architectural discussion on the new table two weeks
 ago, a solution was proposed a week ago and there hasn't been much in the
 way of feedback. Instead, we're going with a change that has had little-
 to-no architectural discussion as was submitted two days ago.

 There will be edge cases that haven't been considered.

 A fundamental question that needs to be considered is this: the current
 patch simply drops meta queries that are considered invalid, ie:

 `WP_Query( [meta_key => key_set_to_bypass_cache] );` will return the
 results of `WP_Query( [post_type => post])` -- this seems like something
 that should be discussed. Should posts be returned in the case, should the
 WHERE clause be modified to `WHERE 1 = 0` or something else entirely.

 In [attachment:"64696-late-meta-flush.diff"] I have made what I think is
 an MVP for avoiding cache invalidation caused by post meta updates:

 * Post meta updates do not invalidate the case
 * When post meta is updated, a cache key is added to record that the
 `WP_Query` meta queries are out of date
 * The next time a post meta query is made, the cache gets invalidated
 * Naming things is hard issues remain in the patch

 With the patch applied, the reproduction steps in the original description
 no longer occur:

 1. Enable a persistent cache
 2. Enable RTC
 3. Open a post in the block editor and keep it open for all the remaining
 steps
 4. Run `wp eval "var_dump( wp_cache_get_last_changed( 'posts' ) );"`
 repeatedly, a few seconds apart
 5. Observe the value no longer changes on every run
 6. Run `wp post list --meta_key=hi`
 7. Re-run `wp eval "var_dump( wp_cache_get_last_changed( 'posts' ) );"`
 8. Observe that the value has changed
 9. Run `wp post list`
 10. Re-run `wp eval "var_dump( wp_cache_get_last_changed( 'posts' ) );"`
 11. Observe the value has not changed

 ----

 I think there are two competing factors:

 * there is broad agreement that RTC both warrants and needs a custom table
 * there are concerns that the custom table needs further discussion

 If that is the case then the safest solution as the release candidate
 approaches is to drop the feature and continue development in the
 Gutenberg plugin, extending the plugin to include the custom table.

 Rushing through major changes to `WP_Query` is a far riskier solution to
 any of the alternatives based on my experience over the last few years.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64696#comment:111>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform