I agree that begin()/commit() should do what they say (which they do now). I'd like to have another construct that behaves like how those two used to (back when there were immediate* functions). Callers would then have code like: $db->enterTransaction() ... atomic stuff ... $db->exitTransaction() This would use counters for nested begins (or perhaps SAVEPOINTs to deal with rollback better...though that can cause RTT spam easily). If using counters, it could be like begin()/finish() in https://gerrit.wikimedia.org/r/#/c/16696/. The main advantage of doing this would be that in cli mode (which defaults to using autocommit), all the code will still start transactions when needed. It would be nice to have the consistency/robustness.
In any case, echoing what Tim said, most code that has begin()/commit() does so for performance reasons. In some cases, they can be changed to use DeferredUpdates or $db->onTransactionIdle(). I had a few patches in gerrit to this affect. Some things may not actually need begin/commit explicitly (I got rid of this in some preferences code ages ago). Things like WikiPage/LocalFile are examples of classes that would have a hard time not using begin()/commit() as they do. Perhaps some code could be restructured in some cases so that the calls at least match, meaning the splitting of transactions would at least be more deliberate rather than accidental.
-- View this message in context: http://wikimedia.7.n6.nabble.com/Can-we-kill-DBO-TRX-It-seems-evil-tp4986002... Sent from the Wikipedia Developers mailing list archive at Nabble.com.