Closed Jud closed 9 years ago
Ping @lox
Hey, sorry for the delay @Jud. Reviewing this and other patches now.
What would you think of actually removing responsibility for issuing SQL entirely from the Transaction object? It already fires events, we could just have the Connection object listening for those events and converting them to SQL. That's probably a cleaner separation of responsibility. Then the API for transactions could remain the same and we could have a Strategy in the Connection to switch between plain old transactions or SAVEPOINTS.
@lox moved the transaction sql into the Connection
object. I'm not entirely sure I see the need for multiple transaction strategies. Using SAVEPOINTS with unnested Pheasant Transactions gives the same behavior as unnested 'plain old transactions'. Nesting 'plain old transactions' doesn't work, and if it is being used, would probably benefit from a working strategy.
I'm pretty happy with this, @harto any thoughts before merge?
Looks good. Just a couple of questions about naming, etc.
@harto @lox Finished up the renaming and also added an event method registerOne
that adds an event listener and removes it after execution.
In this case it was useful for binding to the connection
events commit
message to defer callbacks.
@lox might leave it to you to give this the final :+1:
@lox fwiw, we've been using this in production since October without issue. This was the foundation for allowing all afterSave
/afterDelete
events to run inside transactions.
Closing in favor of #142
We needed this so I hacked it in and added a test case. I ran into trouble getting Mockery to correctly mock the object, so I had to change the tests up a bit.