Custom Conflict Resolution

If you would like to allow for manual conflict resolution by a user, typically this would be implemented separately for each table where manual conflict resolution is required, since the UI to resolve the conflicts would be custom for each.

​

Option 1: Record write conflicts server-side

• Create a table to record write conflicts.
• When the server encounters a conflict, write it to this table, and use appropriate sync rules to sync the data back to the client app.
• The client app can then display these conflicts to the user, and provide an option to resolve the conflicts.

​

Option 2: Record changes as individual rows client-side

• Create a separate table that records individual changes to rows.
• The client updates the original table optimistically, in addition to creating a new change row.
• The server ignores updates to the original table, and only processes the change rows. Each can be marked as “pending” / “processed” / “failed”, with this status being synced back to the client. The client can then display this status for each change to the user if desired, with appropriate logic to manually resolve failed updates.

​

Using CRDTs to Merge Updates Automatically

CRDT data structures such as Yjs can be stored and synced using PowerSync, allowing you to build collaborative apps that merge users’ updates automatically.

See the CRDTs section for more detail.

​

See Also

• Consistency → Validation and conflict handling
• CRDTs