Skip to content
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

Merged
merged 11 commits into from
Aug 6, 2020
Merged

Conversation

zeripath
Copy link
Contributor

@zeripath zeripath commented Aug 1, 2020

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]

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]>
@zeripath zeripath added type/bug issue/critical This issue should be fixed ASAP. If it is a PR, the PR should be merged ASAP backport/v1.12 labels Aug 1, 2020
@zeripath zeripath added this to the 1.13.0 milestone Aug 1, 2020
@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Aug 1, 2020
@GiteaBot GiteaBot added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels Aug 1, 2020
Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
@zeripath zeripath changed the title Critical fix for data loss in V102 migration User transaction in V102 migration Aug 3, 2020
@zeripath zeripath removed backport/v1.12 issue/critical This issue should be fixed ASAP. If it is a PR, the PR should be merged ASAP labels Aug 3, 2020
@zeripath
Copy link
Contributor Author

zeripath commented Aug 3, 2020

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.

@lafriks
Copy link
Member

lafriks commented Aug 3, 2020

In such case rollback should also be moved out of that function

@lunny
Copy link
Member

lunny commented Aug 4, 2020

@zeripath Why removed the backport label?

@zeripath zeripath changed the title User transaction in V102 migration Use transaction in V102 migration Aug 4, 2020
@zeripath
Copy link
Contributor Author

zeripath commented Aug 4, 2020

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.

@GiteaBot GiteaBot added lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. and removed lgtm/need 1 This PR needs approval from one additional maintainer to be merged. labels Aug 5, 2020
@lunny
Copy link
Member

lunny commented Aug 5, 2020

conflicted.

@zeripath
Copy link
Contributor Author

zeripath commented Aug 6, 2020

make lg-tm work

@zeripath zeripath merged commit e17e3f7 into go-gitea:master Aug 6, 2020
@zeripath zeripath deleted the fix-v102-migration branch August 6, 2020 18:16
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. type/bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants