-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run callbacks inside of the same transaction #77
Comments
Perhaps I don't understand the context where you're seeing this behaviour. There's not normally a transaction involved, but if you wrap that in a transaction they'll happen inside the transaction as expected, unless I'm missing something. Mind providing a clearer example to demonstrate the behaviour you think should be changed? |
Here's a test case that should pass. So if any errors are raised in the callbacks, database transaction should be rolled back so that nothing is discarded.
|
Thank you! I understand now. I wasn't thinking about the implicit transaction when you have callbacks. I will have to look at how complex that behaviour would be to add (and how ActiveRecord handles it) to consider whether it makes sense for this gem. This gem is considered feature complete, but at the same time keeping the functionality in line with the existing Rails behaviour does make sense. Thanks for pointing this out! |
Rails implements this behavior in a concern, |
How about you execute
I think the issue mislead this gem's user. Because, the active record's callbacks are in transaction except of |
This seeks to solve issue: jhawthorn#77 Given the situation where a `before/after` callback fails, particularly with related records, we shouldn't still discard records. Note: This is leveraging a private API that exists in [ActiveRecord::Transactions](https://github.com/rails/rails/blob/cd2949d2d936daa89b7e23f816f1c004aee85461/activerecord/lib/active_record/transactions.rb#L345)
This seeks to solve issue: jhawthorn#77 Given the situation where a `before/after` callback fails, particularly with related records, we shouldn't still discard records. Note: This is leveraging a private API that exists in [ActiveRecord::Transactions](https://github.com/rails/rails/blob/cd2949d2d936daa89b7e23f816f1c004aee85461/activerecord/lib/active_record/transactions.rb#L345)
This seeks to solve issue: jhawthorn#77 Given the situation where a `before/after` callback fails, particularly with related records, we shouldn't still discard records. Note: This is leveraging a private API that exists in [ActiveRecord::Transactions](https://github.com/rails/rails/blob/cd2949d2d936daa89b7e23f816f1c004aee85461/activerecord/lib/active_record/transactions.rb#L345)
This seeks to solve issue: jhawthorn#77 Given the situation where a `before/after` callback fails, particularly with related records, we shouldn't still discard records. Note: This is leveraging a private API that exists in [ActiveRecord::Transactions](https://github.com/rails/rails/blob/cd2949d2d936daa89b7e23f816f1c004aee85461/activerecord/lib/active_record/transactions.rb#L345) Co-authored-by: Will Cosgrove <[email protected]>
This seeks to solve issue: jhawthorn#77 Given the situation where a `before/after` callback fails, particularly with related records, we shouldn't still discard records. Note: This is leveraging a private API that exists in [ActiveRecord::Transactions](https://github.com/rails/rails/blob/cd2949d2d936daa89b7e23f816f1c004aee85461/activerecord/lib/active_record/transactions.rb#L345) Co-authored-by: Will Cosgrove <[email protected]>
Describe the bug
Currently the callbacks such as after_discard are run outside of the discarded model's transaction. This can lead to unexpected behavior where, for example, the model is discarded but its' associations discarded in the
after_discard
callback are not.The text was updated successfully, but these errors were encountered: