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

Migrations bug #2206

Closed
Bwko opened this issue Jul 23, 2017 · 12 comments · Fixed by #2460
Closed

Migrations bug #2206

Bwko opened this issue Jul 23, 2017 · 12 comments · Fixed by #2460
Labels
Milestone

Comments

@Bwko
Copy link
Member

Bwko commented Jul 23, 2017

When migrating from gogs db version 16 the following happens:

Migrate v37.go uses the latest models.User. Some of the models.User columns do not exists, like keep_email_private. Resulting in the following error: ERROR: column "keep_email_private" does not exist.

After all migrations are done xorm "magically" creates the missing columns.

Solutions:

  1. Let xorm create all of the missing columns before the migrations.
  2. Only select the columns you need, in this case id & full_name
  3. Always add migrations for new columns
@lafriks
Copy link
Member

lafriks commented Jul 23, 2017

I think 3 is must and if does not have migration, this should be fixed

@lunny
Copy link
Member

lunny commented Jul 24, 2017

@andreynering has contributed https://github.com/go-xorm/xorm/tree/master/migrate. Maybe we can change the migrations method to that?

@Bwko
Copy link
Member Author

Bwko commented Jul 25, 2017

I'd like option 1.
Xorm automatically creates all the columns and I don't see any reason why xorm can't create the columns before migrating.

@bkcsoft
Copy link
Member

bkcsoft commented Jul 26, 2017

@lunny If we switch to that we'll loose all hopes of migrating from Gogs to Gitea in the future

@lafriks
Copy link
Member

lafriks commented Jul 26, 2017

@Bwko that can make problems if you are upgrading from version where later column has been added to structure and in later removed and there is migration that converts it data to either other column or table for example

@lunny
Copy link
Member

lunny commented Jul 26, 2017

@lafriks yes, but that's a bug.

@lunny lunny added the type/bug label Jul 26, 2017
@andreynering
Copy link
Contributor

If we use the Xorm migrate package, even them we would have to keep existing migrations for a while. Also, this don't solve the migration from Gogs problem.

Also keep in mind it is not as stable as the Gorm version since it don't have recent fixes, etc.

There's no easy solution for this.

@Bwko
Copy link
Member Author

Bwko commented Jul 28, 2017

@lafriks You're right, then we need to go for solution 3

@lafriks lafriks added this to the 1.2.0 milestone Aug 3, 2017
@lunny lunny modified the milestones: 1.3.0, 1.2.0 Aug 11, 2017
@sondr3
Copy link
Contributor

sondr3 commented Aug 25, 2017

I was just bit by this issue, and can't upgrade one of my older Gogs instances to the new Gitea 1.2-rc1.

@strk
Copy link
Member

strk commented Aug 25, 2017

@lunny if this bug prevents upgrading from Gogs it should be considered of upmost importance, why postponing fix to 1.3.0 ? Maybe I misunderstood the severity and db 16 is not a supported Gogs version ?

@sondr3
Copy link
Contributor

sondr3 commented Aug 25, 2017

I was upgrading from Gogs version 0.9.48.0722, but I can't tell from the Upgrading from Gogs info on the docs whether it's supported or not. It's not a major hassle for me, it was literally hosting a single repo but wanted to let you know.

@strk
Copy link
Member

strk commented Aug 27, 2017 via email

@lafriks lafriks modified the milestones: 1.2.0, 1.3.0 Sep 4, 2017
@go-gitea go-gitea locked and limited conversation to collaborators Nov 23, 2020
6543 pushed a commit to 6543-forks/gitea that referenced this issue Feb 26, 2024
- This also means that if one of the test fails, it will actually
propagate to make and subsequently fail the test.
- Remove the 'delete duplicates issue users' code, I checked this
against my local development database (which contains quite bizarre
cases, even some that Forgejo does not like), my local instance database
and against Codeberg production and they all yielded no results to this
query, so I'm removing it thus resolving the error that the delete code
was not compatible with Mysql.
- Sync all tables that are requires by the migration in the test.
- Resolves go-gitea#2206

(cherry picked from commit 8e02be7e89a76ccbc3f8a58577be0fcc34e1469e)
(cherry picked from commit 006f06441645d864fc27ca30352367b3afafc5bb)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants