NoSQL
Reserve maintenance kits without accepting a stale decision
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 stock and reservation to Check the reservation’s expected version. Inspect the identity-and-revision decision before attaching the stock condition.
The reservation was formed from one revision of the stock record.
Inspect the component calculation
Check the reservation's expected version( Current stock record: Current stock Reservation request: Reservation proposal )
Examples and results
- Current stock
{ "id": "seal-kit", "version": 4, "units": 8 }- Reservation proposal
{ "id": "seal-kit", "expected_version": 4, "amount": 3 }- Required result
true
- Current stock
{ "id": "seal-kit", "version": 4, "units": 8 }- Reservation proposal
{ "id": "seal-kit", "expected_version": 4, "amount": 9 }- Required result
true
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
This is a deterministic transition model, not a concurrent database, lock or idempotency service. 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.
A matching version on the wrong stock item
This check uses the pieces from “Guard the complete stock change”.
BOTIE
- Current stock
{ "id": "bearing-kit", "version": 7, "units": 6 }- Reservation proposal
{ "id": "seal-kit", "expected_version": 7, "amount": 2 }
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.
If the response is lost after the write, why can a later version mismatch not identify who performed the earlier change?
Unknown outcomes need a stable operation identity and reconciliation beyond this local transition model.
This is a deterministic transition model, not a concurrent database, lock or idempotency service.
Work through the Python challenges →