However, sometimes actions can't be rolled back and it is unfortunately unavoidable. For example, consider when we send emails during the call to process. If we send before saving a record and that record fails to save what do we do? We can't unsend that email.

I too have been confused by behavior like this. Perhaps a clearly defined way to isolate atomic units with synchronous reactivity would help those of us still working through the idiosyncrasies of reactivity.

Allows batch updates by silencing notifications while the fn is running. Example: form.batch(() => { form.change('firstName', 'Erik') // listeners not notified form.change('lastName', 'Rasmussen') // listeners not notified }) // NOW all listeners notified

No need for DatabaseCleaner (rolling back transactions are usually faster than truncate).

transaction calls can be nested. By default, this makes all database statements in the nested transaction block become part of the parent transaction. For example, the following behavior may be surprising: User.transaction do User.create(username: 'Kotori') User.transaction do User.create(username: 'Nemu') raise ActiveRecord::Rollback end end creates both “Kotori” and “Nemu”. Reason is the ActiveRecord::Rollback exception in the nested block does not issue a ROLLBACK. Since these exceptions are captured in transaction blocks, the parent block does not see it and the real transaction is committed.

One workaround is to begin a transaction on each class whose models you alter: