-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Use transaction in V102 migration #12395
Conversation
The code from dropTableColumns has a slightly confusing portion whereby the session is committed for MSSQL but not for other variants. The v102 migration unfortunately missed this subtlety and did not commit the session. This would lead to data loss in the pull_request table on non-MSSQL versions. Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
I've re read this and I see that v102 didn't actually start a transaction so doesn't actually suffer loss - however it really should be in a transaction. |
In such case rollback should also be moved out of that function |
@zeripath Why removed the backport label? |
Because I initially thought that this would always cause data loss I put the backport label in - now I understand that it doesn't start a transaction, the data-loss risk is much much lower and so it probably doesn't need backporting. |
Signed-off-by: Andrew Thornton <[email protected]>
conflicted. |
make lg-tm work |
The code for
dropTableColumns
has a slightly confusing portion whereby the session is committed for MSSQL but not for other variants.The v102 migration doesn't actually start a transaction so this weirdness does not affect it. However it probably should attempt to run this in a transaction.
Signed-off-by: Andrew Thornton [email protected]