Migration error: rename repo is_bare to repo is_empty #2770

New Issue

GiteaMirror · 2025-11-02T04:47:50-06:00

GiteaMirror commented

2025-11-02 04:47:50 -06:00

Originally created by @kimpenhaus on GitHub (Jan 18, 2019).

Gitea version (or commit ref): docker: gitea/gitea:latest
Git version: 2.18.1
Operating system: Docker
Database (use [x]):
- PostgreSQL
- MySQL (10.3.7-MariaDB)
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

I am running gitea inside docker container: gitea/gitea:latest - so I assume this is the latest version. After the last update with watchtower the container won't come up again. Checking the logfiles:

2019/01/18 09:07:18 [I] Migration: rename repo is_bare to repo is_empty
2019/01/18 09:07:18 [...itea/routers/init.go:61 GlobalInit()] [E] Failed to initialize ORM engine: migrate: do migrate: select repositories: Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '"repository" RENAME COLUMN "is_bare" TO "is_empty"' at line 1

Not pretty sure but while rename column works for MySQL I think it is not working in MariaDB. change column should work for both DBs.

MySQL Ref

MaraiDB Ref

Working statement looks like:

ALTER TABLE
    `repository`
CHANGE COLUMN
    `is_bare` `is_empty` tinyint(1);

Originally created by @kimpenhaus on GitHub (Jan 18, 2019).  - Gitea version (or commit ref): docker: gitea/gitea:latest - Git version: 2.18.1 - Operating system: Docker - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL (10.3.7-MariaDB) - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ## Description I am running gitea inside docker container: `gitea/gitea:latest` - so I assume this is the latest version. After the last update with watchtower the container won't come up again. Checking the logfiles: ``` 2019/01/18 09:07:18 [I] Migration: rename repo is_bare to repo is_empty 2019/01/18 09:07:18 [...itea/routers/init.go:61 GlobalInit()] [E] Failed to initialize ORM engine: migrate: do migrate: select repositories: Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '"repository" RENAME COLUMN "is_bare" TO "is_empty"' at line 1 ``` Not pretty sure but while `rename column` works for MySQL I think it is not working in MariaDB. `change column` should work for both DBs. [MySQL Ref](https://dev.mysql.com/doc/refman/8.0/en/alter-table.html) ![bildschirmfoto 2019-01-18 um 10 31 26](https://user-images.githubusercontent.com/575109/51377980-794a9800-1b0c-11e9-9629-b6be45441929.png) [MaraiDB Ref](https://mariadb.com/kb/en/library/alter-table/) ![bildschirmfoto 2019-01-18 um 10 32 14](https://user-images.githubusercontent.com/575109/51377991-7f407900-1b0c-11e9-94d8-0392f3684e8e.png) Working statement looks like: ``` ALTER TABLE `repository` CHANGE COLUMN `is_bare` `is_empty` tinyint(1); ```

GiteaMirror added the type/bug label 2025-11-02 04:47:50 -06:00

GiteaMirror closed this issue

2025-11-02 04:47:50 -06:00

GiteaMirror commented

2025-11-02 04:47:51 -06:00

@zeripath commented on GitHub (Jan 18, 2019):

Sigh. Sorry about this.

@zeripath commented on GitHub (Jan 18, 2019): Sigh. Sorry about this.

GiteaMirror commented

2025-11-02 04:47:51 -06:00

@kimpenhaus commented on GitHub (Jan 18, 2019):

no worries 😄 I am even not pretty sure if MariaDB is one of the supported platforms.

I did manual migration by executing the proper sql statement and setting version to 79. Now it's running again.

@kimpenhaus commented on GitHub (Jan 18, 2019): no worries 😄 I am even not pretty sure if MariaDB is one of the supported platforms. I did manual migration by executing the proper sql statement and setting version to 79. Now it's running again.

GiteaMirror commented

2025-11-02 04:47:52 -06:00

@wyattoday commented on GitHub (Jan 18, 2019):

This also happens on MySQL 8.0 / Percona Server 8.0. Same solution.

@wyattoday commented on GitHub (Jan 18, 2019): This also happens on MySQL 8.0 / Percona Server 8.0. Same solution.

GiteaMirror commented

2025-11-02 04:47:52 -06:00

@xsteadfastx commented on GitHub (Jan 18, 2019):

also in sqlite....

@xsteadfastx commented on GitHub (Jan 18, 2019): also in sqlite....

GiteaMirror commented

2025-11-02 04:47:52 -06:00

@zeripath commented on GitHub (Jan 18, 2019):

If unfortunately you were hit by the migration bug and starting your gitea failed, please follow the below steps:

Stop gitea if it's still running
Change the value of the table version from 79 to 78
Restart gitea

If your version was not 79 you should just run gitea migrate

@zeripath commented on GitHub (Jan 18, 2019): If unfortunately you were hit by the migration bug and starting your gitea failed, please follow the below steps: * Stop gitea if it's still running * Change the value of the table `version` from `79` to `78` * Restart gitea If your version was not 79 you should just run gitea migrate

GiteaMirror commented

2025-11-02 04:47:53 -06:00

@zeripath commented on GitHub (Jan 18, 2019):

Please reply to ensure that you've managed to successfully restart Gitea

@zeripath commented on GitHub (Jan 18, 2019): Please reply to ensure that you've managed to successfully restart Gitea

GiteaMirror commented

2025-11-02 04:47:53 -06:00

@zeripath commented on GitHub (Jan 19, 2019):

Hmm... I've just had a similar issue on sqlite migrating from versions back to v1.5.3 . The migration is still wrong.

@zeripath commented on GitHub (Jan 19, 2019): Hmm... I've just had a similar issue on sqlite migrating from versions back to v1.5.3 . The migration is still wrong.

GiteaMirror commented

2025-11-02 04:47:54 -06:00

@zeripath commented on GitHub (Jan 19, 2019):

@lunny It seems that the problem at least for sqlite is that sess.Sync2 locks the schema which means the drop of the index earlier in the transaction breaks. I'm going to put another PR in for this.

@zeripath commented on GitHub (Jan 19, 2019): @lunny It seems that the problem at least for sqlite is that sess.Sync2 locks the schema which means the drop of the index earlier in the transaction breaks. I'm going to put another PR in for this.

GiteaMirror commented

2025-11-02 04:47:54 -06:00

@michelebugio commented on GitHub (Jan 25, 2019):

I do apologize but my gitea docker instance with sqlite is still down.

I understand I do need to change the value of the version table to 79 manually, but I do not seem to be able to run queries within the docker console. I am sure I am missing something as I've never dealt with sqlite within a docker before, but at this point I would like to make it work.

@michelebugio commented on GitHub (Jan 25, 2019): I do apologize but my gitea docker instance with sqlite is still down. I understand I do need to change the value of the version table to 79 manually, but I do not seem to be able to run queries within the docker console. I am sure I am missing something as I've never dealt with sqlite within a docker before, but at this point I would like to make it work.

GiteaMirror commented

2025-11-02 04:47:54 -06:00

@kimpenhaus commented on GitHub (Jan 25, 2019):

Is your sqlite DB mounted into the docker as volume? If so, you could connect from share or use https://sqlitebrowser.org. If not - I would recommend copying the DB to a volume mount point and then use console or UI.

And you need to change version to 78 ;-)

@kimpenhaus commented on GitHub (Jan 25, 2019): Is your sqlite DB mounted into the docker as volume? If so, you could connect from share or use https://sqlitebrowser.org. If not - I would recommend copying the DB to a volume mount point and then use console or UI. And you need to change version to 78 ;-)

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#2770