Transactions are the mechanism that makes multi-step database operations safe. Without an explicit transaction, a crash or exception halfway through two related writes can leave your data in an inconsistent state — for example, a user row written but its corresponding account row missing. Cindel’sDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/mainser/cindel/llms.txt
Use this file to discover all available pages before exploring further.
writeTxn and readTxn helpers let you group any number of operations into a single atomic unit so either all of them succeed together or none of them are visible at all.
Write Transactions — writeTxn
Wrap any set of writes in writeTxn to commit them all together. If the callback throws — for any reason — Cindel rolls back all pending changes and watchers are not notified:
Future<T> Function(), so you can return a value:
Rollback on Exception
If your callback throws, Cindel catches the exception, rolls back the native transaction, rethrows the original error, and skips all watcher notifications for that transaction:Read Transactions — readTxn
readTxn provides a consistent snapshot of the database for the duration of the callback. Every read inside readTxn sees the same logical version of the data even if another isolate or write transaction commits in the middle:
put or delete) inside a readTxn throws CindelTransactionError immediately:
Why Transactions Matter
Atomicity Across Collections
When you write to two collections that must always be in sync — for example, creating a user and provisioning its account at the same time — wrapping both writes in a singlewriteTxn ensures the change is atomic:
put calls would leave a user row without a corresponding account row.
Consistent Multi-Read Snapshots
Without a read transaction, two sequential reads might observe different versions of the data if a concurrent write commits between them.readTxn pins the snapshot:
Auto-Wrapping for Single Writes
Single writes outside an explicit transaction are auto-wrapped by Cindel internally, so they are still atomic. This means callingdb.users.put(ada) directly is safe — it will not partially commit. The recommendation to use explicit writeTxn applies specifically when you need multiple writes to succeed or fail together:
Nested Transactions
Cindel does not support nested transactions. CallingwriteTxn or readTxn while already inside a transaction on the same database handle throws CindelTransactionError:
Query-Based Mutations Inside writeTxn
Query-based updateAll and deleteAll can be called inside an explicit writeTxn on native backends (both MDBX and SQLite). They participate in the same transaction and will be rolled back on failure: