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

 Replying to [comment:59 JoeFusco]:
 > Replying to [comment:57 peterwilsoncc]:
 >
 > > @JoeFusco My reading of Matt's comment above is that the addition of
 one table has been authorized for the current and future RTC features.
 It's a very rare occurrence so we're not going to be able to slide in two
 when it's possible to use one.
 >
 > Agreed - one table for sync, no argument there.

 I really don't like dealing with disingenuous comments. My comment is
 perfectly clear that my understanding is there is approval to add one (1)
 table in total to WordPress 7.0, bringing the total number of tables in
 WordPress to thirteen (13) in a single site install. To pretend to
 interpret my comment as anything else is very unhelpful.

 It took a week of delaying to even get this discussion started, let's not
 waste further time with deliberate misinterpretations.

 For the purposes of awareness updates, I don't see that a unique index is
 absolutely needed. Helpful, sure but not something that warrents another
 table.

 For most requests, the table will be updated so we can run something along
 the lines of

 {{{#!sql
 UPDATE `wp_collaboration`
    SET event_time = NOW()
    WHERE room = 'room1' AND event = 'awareness' AND client_id = 'client2'
 }}}

 If no rows are affected, that implies that the client is signing on and an
 insert is required.

 Yes, if two concurrent requests occur there is a slim chance two rows will
 be created but that should be an exceptionally rare circumstance: the
 polling client waits for the apiFetch promise to complete before
 scheduling the next polling event. You can see this in affect by
 throttling network requests.

 As @czarate mentions above, there is a chance that other items will need
 to be considered as part of the real time collaboration feature. Rather
 than targeted, endpoint specific tables, we need to write a table that
 meets the requirements of what is known today and the unknown of tomorrow.

 ----

 Re: requiring a persistent cache: I don't think this is a good idea, I
 just see it as a handy place to shift awareness if it's available. Similar
 to transients but without the options table.

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