DB topic.name uses varying(25) which makes mirrors of repos with long topics fail #6569

New Issue

GiteaMirror · 2025-11-02T06:59:52-06:00

GiteaMirror commented

2025-11-02 06:59:52 -06:00

Originally created by @michaelx on GitHub (Dec 22, 2020).

Gitea version: 1.13.0 (also fails on latest dev)
Git version: 2.26.2
Operating system:
- docker-compose with the image gitea/gitea:1
Database:
- PostgreSQL

Description

Create new migration
Select GitHub
Clone https://github.com/survivejs/webpack-book as a mirror
Will fail with:

Migrate repository from https://github.com/survivejs/webpack-book failed: pq: value too long for type character varying(25)

Can be solved by using varying(255) on topic.name. Is there a reason it's limited to 25?

Originally created by @michaelx on GitHub (Dec 22, 2020). - Gitea version: 1.13.0 (also fails on latest dev) - Git version: 2.26.2 - Operating system: - `docker-compose` with the image `gitea/gitea:1` - Database: - [x] PostgreSQL ## Description 1. Create new migration 2. Select GitHub 3. Clone `https://github.com/survivejs/webpack-book` as a **mirror** 4. Will fail with: ``` Migrate repository from https://github.com/survivejs/webpack-book failed: pq: value too long for type character varying(25) ``` Can be solved by using `varying(255)` on `topic.name`. Is there a reason it's limited to 25?

GiteaMirror added the topic/repo-migration type/bug labels 2025-11-02 06:59:52 -06:00

GiteaMirror closed this issue

2025-11-02 06:59:53 -06:00

GiteaMirror commented

2025-11-02 06:59:53 -06:00

@lunny commented on GitHub (Dec 22, 2020):

We need index the column, so it shouldn't too big. How many characters with Github Topic name? 🤔

@lunny commented on GitHub (Dec 22, 2020): We need index the column, so it shouldn't too big. How many characters with Github Topic name? 🤔

GiteaMirror commented

2025-11-02 06:59:54 -06:00

@michaelx commented on GitHub (Dec 22, 2020):

The one it fails with is 26, but I think it would be fine to just drop topics that are too long on migration. Gitea shouldn't fail just because of it though. What do you think?

@michaelx commented on GitHub (Dec 22, 2020): The one it fails with is 26, but I think it would be fine to just drop topics that are too long on migration. Gitea shouldn't fail just because of it though. What do you think?

GiteaMirror commented

2025-11-02 06:59:54 -06:00

@lunny commented on GitHub (Dec 22, 2020):

@michaelx Good idea! We need a PR to fix that.

@lunny commented on GitHub (Dec 22, 2020): @michaelx Good idea! We need a PR to fix that.

GiteaMirror commented

2025-11-02 06:59:54 -06:00

@michaelx commented on GitHub (Dec 22, 2020):

PR is up for grabs as this isn't my stack, I am afraid. Thanks.

@michaelx commented on GitHub (Dec 22, 2020): PR is up for grabs as this isn't my stack, I am afraid. Thanks.

GiteaMirror commented

2025-11-02 06:59:54 -06:00

@zeripath commented on GitHub (Dec 22, 2020):

it certainly appears that there is no limit in GH

@zeripath commented on GitHub (Dec 22, 2020): it certainly appears that there is no limit in GH

GiteaMirror commented

2025-11-02 06:59:54 -06:00

@Vitexus commented on GitHub (Dec 23, 2020):

I confirm that error:

2020/12/23 00:01:16 modules/task/task.go:51:handle() [E] Run task failed: Error 1406: Data too long for column 'name' at row 1

Is it an typo ? All other names in database are 255 chars long.
I'll fix it manually in my db using

ALTER TABLE `topic` CHANGE `name` `name` VARCHAR(255);

After that migration was successfull

@Vitexus commented on GitHub (Dec 23, 2020): I confirm that error: ``` 2020/12/23 00:01:16 modules/task/task.go:51:handle() [E] Run task failed: Error 1406: Data too long for column 'name' at row 1 ``` **Is it an typo ?** All other `name`s in database are 255 chars long. I'll fix it manually in my db using ```mysql ALTER TABLE `topic` CHANGE `name` `name` VARCHAR(255); ``` After that migration was successfull

GiteaMirror commented

2025-11-02 06:59:55 -06:00

@zeripath commented on GitHub (Dec 24, 2020):

it's partly to do with the fact that they're indexed but I suspect it's an incorrect decision and we should just increase that field and either make it be indexed with bleve or just deal with it.

@zeripath commented on GitHub (Dec 24, 2020): it's partly to do with the fact that they're indexed but I suspect it's an incorrect decision and we should just increase that field and either make it be indexed with bleve or just deal with it.

GiteaMirror commented

2025-11-02 06:59:55 -06:00

@Vitexus commented on GitHub (Dec 25, 2020):

I didn't provide pull request cause i don't know right final solution. It was only dirty hotfix. I'm looking forward fixed version.

@Vitexus commented on GitHub (Dec 25, 2020): I didn't provide pull request cause i don't know right final solution. It was only dirty hotfix. I'm looking forward fixed version.

GiteaMirror commented

2025-11-02 06:59:55 -06:00

@Vitexus commented on GitHub (Dec 25, 2020):

Please note: NOT ONLY POSTGRES
I use MariaDB with the same problem.

@Vitexus commented on GitHub (Dec 25, 2020): Please note: **NOT ONLY POSTGRES** I use MariaDB with the same problem.

GiteaMirror commented

2025-11-02 06:59:55 -06:00

@somera commented on GitHub (Dec 25, 2020):

In which Gitea version it will be fixed?

@somera commented on GitHub (Dec 25, 2020): In which Gitea version it will be fixed?

GiteaMirror commented

2025-11-02 06:59:56 -06:00

@lunny commented on GitHub (Dec 25, 2020):

A simple solution is to change to a big size i.e. 50 , but that may also not enough?

@lunny commented on GitHub (Dec 25, 2020): A simple solution is to change to a big size i.e. 50 , but that may also not enough?

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#6569