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

 > Hopefully we can leverage this for Playground sync in the future as
 well.

 For Playground<->Playground, where we can log every database query,
 potentially. For WordPress<->Playground and WordPress<->WordPress we'd
 need a dedicated data structure.

 For synchronizing the files, we can get away with a simple text-based
 index file. The [https://github.com/adamziel/streaming-site-migration site
 import tool] I'm building right now can synchronize file deltas based on a
 TSV file with this layout: `base64 file path | last modified date | size`.
 It doesn't version the database rows, though, It just overwrites the
 entire database on every sync.

 @dmsnell and I [https://github.com/adamziel/zs-sync/blob/trunk/schemas/
 explored synchronizing the databases]. The solution is in knowing when
 something in the database changes, e.g. a table is created, a column is
 added, these specific rows are updated. In an unconstrained environment,
 we could keep track of it with a write-ahead log using a database
 extension or a clever set of triggers. When that's not an option, the next
 best thing is using WordPress hooks before every SQL query and,
 independently, running a slow-paced indexer via wp-cron. That indexer
 would need a data backend where the indexed rows can be found with a very
 low cost. The best solution we've found for that was using five different
 tables, each with a schema resembling `indexed_table_name |
 indexed_primary_key | last_modified_date | hash | version_number`.

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