3 ms·
It would have an implicit transaction, wouldn't it? Think about what we both wrote here (sans the weak man argument, of course I'm talking about updates).
by Rapzid 4y ago
It would have an implicit transaction, wouldn't it?
Think about what we both wrote here (sans the weak man argument, of course I'm talking about updates).
- jemmyw 4y agoI see. Well you could have been more explicit in your original message, I don't think it was obvious at all that you were talking about updates. Rails does the right thing here in my opinion. Anything that happens between calling `.save` and it returning should be in the safe envelop of a transaction. It can't know that you're only going to emit a single UPDATE query in that transaction, plus the framework user expects any exception between calling save and it returning to roll back. There are outs if you need them. I've worked on a few reasonably high traffic and complex rails applications and I don't recall a time when the time between the last query and the commit caused an issue. Yes times when the transaction itself had got too large and that commit was taking awhile. That said, there were more of these types of locking issues in the project I worked on 10 years ago with MySQL and repeatable read isolation level than with PG since then which defaults to read committed.