Use Custom Write Checkpoints to handle asynchronous data uploads, as in chained data pipelines.
uploadData
call completes.
Problems occur if the persistence in the source database happens asynchronously. If the client’s upload is meant to mutate the source database (and eventually does), but this is delayed, it will effectively seem as if the client’s uploaded changes were reverted on the server, and then applied again thereafter.
Chained data pipelines are a common example of asynchronous uploads — e.g. data uploads are first written to a different upstream database, or a separate queue for processing, and then finally replicated to the ‘source database’ (to which PowerSync is connected).
For example, consider the following data pipeline:
HEAD
in the source database, and creates a Write Checkpoint for the client. The Write Checkpoint number is returned and recorded in the client.HEAD
(but the changes are still not present in the source database).HEAD
.checkpoints
table, which should contain the following checkpoint payload information in some form:
checkpoints
in this example) need to enabled.
For Postgres, this involves adding the table to the PowerSync logical replication publication, for example:
write_checkpoints
sync event in your Sync Rules configuration. This event should map the rows from the checkpoints
table to the CheckpointPayload
payload.
uploadData
method. The Write Checkpoint number should be supplied to the CRUD transactions’ complete
method.
user_id
and client_id
.
checkpoints
records: