fadb6830f8
Based on https://github.com/rails/rails/pull/52017 One concern raised by Xavier is users holding on the return value of `.current_transaction` beyond the point where it is committed / rolled back / invalidated. I believe this is an invalid use of the API, just like holding `ActiveRecord::Base.connection` beyond the scope of a request is. However we can be more explicit about it, so I changed the callback registration methods to raise an error when called on a finalized transaction. Another concern was the usability of the null-object in the Active Record notification payloads, and I agree that while the null-object make sense when calling `Model.current_transaction`, it doesn't make sense to include it in the payload of events. The goal of the `.current_transaction` API is to allow implementing transaction aware code in a streamlined way. The goal of the `:transaction` in events however it to allow logging whether a query was inside a transaction or not, so it's much more ergonomic for it to be nilable. So I kept Matthew's change that passes `transaction: nil` in `sql.active_record` events when not inside a transaction. I also added test coverage to make sure it behaves consistently whether we're inside a transactional test or not. I also kept the separation between internal and "user" transaction objects, as I think it's a nice way to limit the effectively exposed API, and prevent users from abusing that API too much. Co-Authored-By: Jean Boussier <jean.boussier@gmail.com> |
||
|---|---|---|
| .. | ||
| active_record/connection_adapters | ||
| activejob | ||
| assets | ||
| cases | ||
| fixtures | ||
| migrations | ||
| models | ||
| schema | ||
| support | ||
| config.example.yml | ||
| config.rb | ||