We have several Drupal sites set up running on MSSQL, running a multi-master replication scheme (Merge Replication). The way PK conflict avoidance is handled in this scheme is by assigning different ranges of an autoincrementing PK to different nodes (e.g. DB1 has 1-1000, DB2 has 1001-2000, etc.). This poses issues for us in editing content as node_revision VIDs appear to be prioritized and ordered by vid, rather than timestamp. This can lead to pages being in an uneditable state without intervention from a DBA as a vid may jump a significant number of numbers. Currently, the only resolution is to revise the high-numbered revision to generate an appropriate low numbered one, then deleting the offending node_revision.
I would imagine that the fix would be to use the PK as an identifier only, sorting and prioritizing based on last modified timestamp.
Postponed: needs info
11.0 🔥
node system
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Is this still something we want to consider? Our generic revision UI also sorts by revision id.
Bumping this again to see if anyone feels strongly about this? I would prefer to keep it by revision id.