Conversation
…ove useless composer cache step
|
Edit: hold on, still testing some things. Edit again: It's good. |
shvlv
left a comment
There was a problem hiding this comment.
I'm really afraid of transactions in the WordPress context because of 100+ different plugins doing something in the DB, but we have it already, and it's a nice improvement. It should be a consumer's responsibility to use this carefully.
There was a problem hiding this comment.
This filename is odd. I think transaction is a single word 😄
johnhooks
left a comment
There was a problem hiding this comment.
I agree with @shvlv, user beware.
I approve.
I was playing with something similar. I had trouble with WP-Browser and testing logic that used transactions because of the transaction that WP-Browser wraps around the test.
I accounted for it (or another plugin using transactions) with:
SELECT @@in_transaction;But I knew I was running a newer database and it was available.
Main Changes
Adds support for nested database transactions. Using
DB::beginTransaction()with other existing transactions causes MySQL/MariaDB to commit all existing transactions when it encounters aSTART TRANSACTION.Instead, we now properly create savepoints and restore them when utilizing more than 1 transaction. This is similar to what Laravel does for their lockForTransaction functionality.
As wp-browser starts transactions as well, this allows us to start and rollback and initial transaction in tests, so we're creating savepoints instead of committing all of wp-browsers previous transactions in tests: