Checkpoint Requests - #549
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
|
|
||
| Before creating a checkpoint request: | ||
|
|
||
| 1. Use a PowerSync Swift SDK release that supports the alpha checkpoint request API. |
There was a problem hiding this comment.
We should mention the specific min. version here so developers don't have to spend time looking it up
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
|
|
||
| The client only updates its local state when it has all the data matching a checkpoint, and then it updates the state to exactly match that of the checkpoint. There is no intermediate state while downloading large sets of changes such as large server-side transactions. Different tables and [buckets](/architecture/powersync-service#bucket-system) are all included in the same consistent checkpoint, to ensure that the state is consistent over all data in the client. | ||
|
|
||
| Alpha [Checkpoint Requests](/client-sdks/advanced/checkpoint-requests) let you wait until the local database has applied a new point-in-time checkpoint after the initial sync. |
There was a problem hiding this comment.
This sentence reads oddly without an article: "Alpha Checkpoint Requests let you...". Consider "The alpha Checkpoint Requests API lets you..." to match the phrasing used in the note added to custom-write-checkpoints.mdx ("The alpha Checkpoint Requests API uses the term...").
| You can create an explicit checkpoint request while local writes are waiting to upload. PowerSync does not apply the requested checkpoint while those writes are pending. After the upload queue is empty, the PowerSync Client SDK creates another checkpoint request as its upload target. If the explicit request was created first, this upload target has a newer request ID, supersedes the earlier request, and captures a source position after the upload has completed. | ||
|
|
||
| `waitForSync()` considers the explicit request complete when the same or a newer checkpoint request has been applied locally. If the explicit request is created after the upload target instead, it captures an even later source position. You can therefore write locally and wait for the uploaded result to return through sync: | ||
|
|
There was a problem hiding this comment.
This paragraph lays out two orderings (explicit request created before vs. after the automatic upload-target request), and the example right after opens with "You can therefore...", reading as if it follows from the second case only. Given the example calls requestCheckpoint() immediately after execute(), it looks like it actually demonstrates the first case (explicit request created before the upload target). Worth confirming which case the example maps to, or rephrasing to "In either case, you can write locally and wait..." so it isn't read as tied to just the scenario immediately above it.
| 1. Use PowerSync Swift SDK v1.16.0 or greater. | ||
| 2. Run PowerSync Service version 1.24.0 or later. |
There was a problem hiding this comment.
"v1.16.0 or greater" and "version 1.24.0 or later" phrase the same kind of version constraint two different ways back to back. Consider making these consistent, e.g. "version 1.16.0 or later" / "version 1.24.0 or later".
2 participants
This adds docs for the newly introduces Checkpoints Requests function. Resolves #543
This feature is currently only supported in the Swift SDK. This should be ported to other SDKs in the near future.
For context. See these links:
TODO:
AI usage: I initially hand-wrote a first draft, then piped that in as context for Codex 5.6 Sol to make these changes.