-
-
Notifications
You must be signed in to change notification settings - Fork 627
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Confusion about transaction code: #1618
Comments
beginTransaction / commit / rollback are just simple helpers to perform To me 3rd example is the most correct but I'm not an SQL / mysql expert Possible reasons why Not sure when |
there was a discussion somewhere here about possible better helper api that would handle this pattern, for example something similar to https://github.com/porsager/postgres#transactions ( I've started some initial work here ) |
I think the first one is wrong, because cn is in try, catch can't get the reference And in the experience of some other languages (such as java), the opening of the transaction will also be put outside the try, because the failure of the transaction to open does not actually need to be rolled back, only if there is an error during the execution process, it will be rolled back. capture |
thanks for the fantastic info @sidorares . I'm sure this will be helpful to others also. Additionally it's one of those cases where on the internet, there is some bad/incorrect example code, which gets repeatedly copied. Thanks again, mysql2 is totally incredible (Just FYI there was a delay with ghub notifying these comments, thanks again.) |
Isn't the point of transactions, to isolate a group of query/execute commands? If, for some reason, Some back-off/retry on |
@trasherdk in the example above if beginTransaction fails the control goes to catch block |
@sidorares If by example above, you mean: const cn = await pool.getConnection()
try {
await cn.beginTransaction()
await cn.execute(' ...
await cn.execute(' ...
await cn.commit()
}
catch {
await cn.rollback()
} Then I'd expect you to be right. |
Yes, currently you are expected to handle this manually. There is definitely a room for improvement, feel free to suggest your api |
Well, the snippet I quoted, is how I would expect the flow to go. I'd probable throw in a few SELECT ... LOCK IN SHARE MODE and SELECT ... FOR UPDATE before any |
we could have a helper like this as a replacement for beginTransaction / commit / rollback: const result = await connection.transaction(async connection => {
connection.execute(/*...*/);
return connection.query(/*...*/);
})
// also pool - a shortcut for pool.getConnection + connection.transaction
await pool.transaction(async connection => {
connection.execute(/*...*/);
connection.query(/*...*/);
}) wdyt @trasherdk ? |
If // also pool - a shortcut for pool.getConnection + connection.transaction
await pool.transaction(async connection => {
await connection.execute(/*...*/);
const [ cols, rows ] = await connection.query(/*...*/);
}) But how is // also pool - a shortcut for pool.getConnection + connection.transaction
await pool.transaction(async connection => {
await connection.execute(/*...*/);
const [ cols, rows ] = await connection.query(/*...*/);
connection.commit()
}).catch(error) {
connection.rollback()
} It might be better to bake the
|
My transaction code:
But am I wrong? Should it be:
But wait! Should it be?
I'm afraid I don't know the answer. Thanks in advance anyone who can advise. (It may help others also?)
The text was updated successfully, but these errors were encountered: