Skip to content

Fix migration order v1.3 #3157

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

Merged
merged 7 commits into from
Dec 12, 2017

Conversation

lafriks
Copy link
Member

@lafriks lafriks commented Dec 11, 2017

Specific to 1.3.x release when upgrading from 1.2.x
Fixes #3155

PR to fix on master branch will follow in other PR so that there is no problems when upgrading from 1.2.x and 1.3.x to 1.4.0

@sapk
Copy link
Member

sapk commented Dec 11, 2017

LGTM

@tboerger tboerger added the lgtm/need 1 This PR needs approval from one additional maintainer to be merged. label Dec 11, 2017
@lafriks
Copy link
Member Author

lafriks commented Dec 11, 2017

Did file name renames to match real migration version, so diff does looks bigger than actual changes are because of that

Copy link
Member

@ethantkoenig ethantkoenig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there any changes to the migrations (other than reordering/renaming)? It's hard to tell with the diff.

@@ -59,6 +59,10 @@ type Version struct {
Version int64
}

func emptyMigtation(x *xorm.Engine) error {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

omg :) thanks :)

@lafriks
Copy link
Member Author

lafriks commented Dec 12, 2017

@ethantkoenig Not really, just skipping column drop errors (in case migration is being run second time)

@lafriks
Copy link
Member Author

lafriks commented Dec 12, 2017

@ethantkoenig fixed typo

Copy link
Member

@ethantkoenig ethantkoenig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, just one nit: could we add comments to where errors are ignored? It will help future readers understand what's going on, and may be useful if there turns out to be something wrong in this PR (hopefully not, but let's be safe).

@lafriks lafriks force-pushed the fix/rel_1_3_migration_order branch from 8d28831 to 563db61 Compare December 12, 2017 00:57
@lafriks
Copy link
Member Author

lafriks commented Dec 12, 2017

@ethantkoenig added comment before ignored error warn log message

@ethantkoenig
Copy link
Member

ethantkoenig commented Dec 12, 2017

LGTM see below

@tboerger tboerger 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 Dec 12, 2017
@@ -18,6 +18,7 @@ func removeIndexColumnFromRepoUnitTable(x *xorm.Engine) (err error) {
log.Warn("Unable to drop columns in SQLite")
case setting.UseMySQL, setting.UsePostgreSQL, setting.UseMSSQL, setting.UseTiDB:
if _, err := x.Exec("ALTER TABLE repo_unit DROP COLUMN `index`"); err != nil {
// Ignoring this error in case we run this migration second time (after migration reordeting)
Copy link
Member

@ethantkoenig ethantkoenig Dec 12, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are not ignoring this error. Also typo (reordeting)

EDIT: I meant we are not currently ignornig this error; I did not mean that we shouldn't ignore this error. Sorry for any confusion

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then there is no way to fix this error

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least I don't see how we can fix to run 3 migrations again that were not run for all who upgraded from 1.2 -> 1.3 without running them for all and ignoring this error

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what you mean; can't we just replace the return with log.Warn?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ethantkoenig I already do log.Warn this error, see code below this comment. By ignoring I meant we do not fail migration by returning error

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

line 22 (directly beneath this comment) is a return statement

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ooooh... Sry, just woke up and did not have my coffee yet :))) I thought you are saying this error can't be ignored but I just have added comment also to wrong file :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought you are commenting on v51 migration where there is log.Warn and same comment

Copy link
Member

@ethantkoenig ethantkoenig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - I don't want to block an important bug fix, so we can fix nits later

@lafriks
Copy link
Member Author

lafriks commented Dec 12, 2017

@ethantkoenig fixed :)

@lafriks lafriks changed the title FIx migration order v1.3 Fix migration order v1.3 Dec 12, 2017
@michaelkuhn
Copy link
Contributor

Thanks for fixing this so quickly! One note, though: It might be a good idea to add a comment to migrations.go to never ever reorder migrations so this does not happen again in the future.

@lafriks
Copy link
Member Author

lafriks commented Dec 12, 2017

Yes, I will add comment in master branch code

@lunny lunny merged commit 4b187f5 into go-gitea:release/v1.3 Dec 12, 2017
@moritz-h
Copy link

@lafriks Are there any corruptions to the database when I have already upgraded to 1.3 and if yes will this also be automatically fixed?
I'm currently on 1.3.0, which was upgraded from a fresh 1.2.3 installation and have the same log entries as in the issue report.

@lafriks
Copy link
Member Author

lafriks commented Dec 12, 2017

@moritz-h there is just missing migrations so some features might not work as expected. Yes, 1.3.2 release will fix that.

@lafriks lafriks deleted the fix/rel_1_3_migration_order branch December 12, 2017 17:07
@sapk
Copy link
Member

sapk commented Dec 12, 2017

@lafriks maybe we should add a deprecated message on 1.3.X releases messages when 1.3.2 is release ? To indicate the existing bug.

@lafriks
Copy link
Member Author

lafriks commented Dec 12, 2017

All not latest minor versions should be considered deprecated by default :)

@go-gitea go-gitea locked and limited conversation to collaborators Nov 23, 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.

7 participants