[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 JoeFusco):

 @peterwilsoncc You're right, your comment:57 was clear — I misread the
 scope and should have treated awareness as part of the same one-table
 decision. Apologies for the confusion.

 Thank you for your input throughout this discussion.
 -----
 Per Matt's request
 (https://wordpress.slack.com/archives/C18723MQ8/p1773557762033729) here is
 the table definition for review.


 == `wp_collaboration`

 One table for sync updates and awareness. Replaces the post meta approach
 from prior Betas.

 {{{#!sql
 CREATE TABLE wp_collaboration (
    id bigint(20) unsigned NOT NULL auto_increment, -- also serves as the
 polling cursor
    room varchar(191) NOT NULL default '',          -- e.g.
 postType/post:123, LIKE-able
    type varchar(32) NOT NULL default '',           -- update, sync_step1,
 sync_step2, compaction, awareness
    client_id varchar(32) NOT NULL default '',      -- one per browser tab
    user_id bigint(20) unsigned NOT NULL default '0',
    update_value longtext NOT NULL,
    date_gmt datetime NOT NULL default '0000-00-00 00:00:00',
    PRIMARY KEY  (id),
    KEY room (room,id),                             -- covers polling:
 WHERE room = %s AND id > %d
    KEY date_gmt (date_gmt)                         -- covers cron cleanup:
 WHERE date_gmt < %s
 );
 }}}

 No UNIQUE KEY - sync rows need multiple entries per room+client. Awareness
 deduplication uses UPDATE-then-INSERT at the application level (per
 comment:63). A future Awareness API could move awareness to its own table
 with a proper UNIQUE KEY, eliminating this application-level workaround.

 Compaction periodically collapses sync rows (threshold: 50), so the table
 stays bounded during a session. A daily cron
 (`wp_delete_old_collaboration_data`) removes sync rows older than 7 days
 and awareness rows older than 60 seconds.

 When a persistent object cache is available, awareness reads skip the DB
 entirely.

 https://github.com/WordPress/wordpress-develop/pull/11256

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