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

 Replying to [comment:51 mindctrl]:

 > Content updates are append-only messages that must be reliably delivered
 to every client exactly once. ... Reliable delivery matters, as a missed
 or duplicated update means a diverged document.

 Small point of clarity: At-least-once delivery is OK, if not ideal.
 Merging an already-applied update is effectively a no-op (assuming the
 update has not been modified in any way). A missed update, on the other
 hand, is destructive.

 Otherwise I agree with your case for a second table.

 > Regardless of the backing implementation (Yjs or otherwise), any
 collaborative editing system needs to identify its clients and distinguish
 between types of sync data. If the table is holding multiple types of
 data, we'll always need to know what type we have, and preferably query
 for only the data needed at any given time.

 While I don't think the overhead of filtering results from an "over-query"
 is that bad, I agree with this in general—as long as we represent both
 `client_id` and `type` flexibly in the schema. Both should probably be
 `VARCHAR`s with reasonably future-proof sizes?

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