A transaction is a series of updates on a table that are either all persisted together or are not persisted at all. They enable a table to have atomicity.
In JSDB, we write out our tables in JavaScript Data Format (JSDF), which is a transaction log in pure JavaScript. (Transaction log, in this case – confusingly – refers to a single update, not an atomic batch update).
To implement transactions (atomicity for batch changes) in JSDF, we can wrap multiple changes into a single-line immediately-invoked function expression (IIFE) and add that to our append-only log.
At this point we can be reasonably certain that transaction-1 has persisted to disk.
Note 1:transaction-1 is an arbitrary name, you can use any string that’s a valid identifier but it must start and end with two underscores and you must use the same identifier for any change that you want to include in your transaction.
Note 2: atomic transactions will only be implemented at the table-level (not the database-level, which would be a far messier undertaking and can be avoided by designing your tables accordingly).
A transaction is a series of updates on a table that are either all persisted together or are not persisted at all. They enable a table to have atomicity.
In JSDB, we write out our tables in JavaScript Data Format (JSDF), which is a transaction log in pure JavaScript. (Transaction log, in this case – confusingly – refers to a single update, not an atomic batch update).
To implement transactions (atomicity for batch changes) in JSDF, we can wrap multiple changes into a single-line immediately-invoked function expression (IIFE) and add that to our append-only log.
e.g.,
Without a transaction, the changes would be written out like this instead:
In keeping with as transparent an API as possible, here is one way we can implement this functionality:
At this point we can be reasonably certain that transaction-1 has persisted to disk.
Note 1:
transaction-1
is an arbitrary name, you can use any string that’s a valid identifier but it must start and end with two underscores and you must use the same identifier for any change that you want to include in your transaction.Note 2: atomic transactions will only be implemented at the table-level (not the database-level, which would be a far messier undertaking and can be avoided by designing your tables accordingly).
Mirrors internal issue: #1