SQL
Checkpoint a versioned maintenance-reading batch
BOTIE
Examples, experiments and workspace controls
Connect a tool's inputs to see what it produces. You can try a branch before connecting it to Result.
Try your own inputs
Use a copy of the example to try your own data. Keep the problem's assumptions in mind, and predict the effect of a change before checking the output. You can also add another branch to compare two ways of doing the calculation.
Context for this challenge
Connect source changes and committed cursor to Keep changes after the ingestion cursor. Inspect the ordered batch before merging record versions.
A source delivers corrections, deletions and late records after the last committed position.
Inspect the component calculation
Keep changes after the ingestion cursor( Source changes: Incoming source changes Committed cursor: Committed ingestion sequence )
Examples and results
- Incoming source changes
[ { "seq": 11, "id": "R1", "version": 2, "deleted": false, "value": 22 }, { "seq": 12, "id": "R2", "version": 2, "deleted": true, "value": null } ]- Committed ingestion sequence
10
- Required result
[ { "seq": 11, "id": "R1", "version": 2, "deleted": false, "value": 22 }, { "seq": 12, "id": "R2", "version": 2, "deleted": true, "value": null } ]
- Incoming source changes
[]
- Committed ingestion sequence
10
- Required result
[]
Try a fresh construction
This clears this draft, including its undo history. Earlier successful attempts stay recorded. Build again without opening hints to record an independent attempt.
Stuck? Inspect a worked construction
The tools below form one possible solution. You can assemble it, follow its signals, and undo that change to return to your own construction.
Assumptions and test precision
The widget returns a checkpoint record but does not persist it. The SQL exercise demonstrates atomic sink/cursor commit in one isolated database. Numerical tests allow a difference of 0.001. Lists and structures must also have the right shape.
Your last tested pieces can start the full construction. An existing draft there keeps its own pieces.
One replayed position and one genuinely new identity
This check uses the pieces from “Merge a batch and advance its checkpoint”.
BOTIE
- Stored versioned readings
[ { "id": "R1", "version": 2, "deleted": false, "value": 25 } ]- Incoming source changes
[ { "seq": 20, "id": "R1", "version": 2, "deleted": false, "value": 25 }, { "seq": 21, "id": "R4", "version": 1, "deleted": false, "value": 16 } ]- Committed ingestion sequence
20
Use a number, text, or an array matching the requested result. For a matrix, put each row in brackets. Saving your prediction runs your current construction on these inputs and checks the earlier examples too.
Build a construction in the workspace above first. This case will test those pieces.
What failure could occur if the checkpoint commits before the records it describes?
Keep cursor and data effects recoverable together, and reconcile the sink with a trusted complete view.
The widget returns a checkpoint record but does not persist it. The SQL exercise demonstrates atomic sink/cursor commit in one isolated database.
Work through the SQL challenges →