6 Matching Annotations
- Oct 2020
-
github.com github.com
-
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.
-
- Aug 2020
-
final-form.org final-form.org
-
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
-
- Jun 2020
-
github.com github.com
-
No need for DatabaseCleaner (rolling back transactions are usually faster than truncate).
-
-
api.rubyonrails.org api.rubyonrails.org
-
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.
How is this okay??
When would it ever be the desired/intended behavior for a
raise ActiveRecord::Rollback
to have absolutely no effect? What good is the transaction then??What happened to the principle of least surprise?
Is there any reason we shouldn't just always use
requires_new: true
?If, like they say, the inner transaction "become[s] part of the parent transaction", then if anything, it should roll back the parent transaction too — not roll back nothing.
-
One workaround is to begin a transaction on each class whose models you alter:
-
- Apr 2020
-
stackoverflow.com stackoverflow.com