[Bug][Module Name] Migration to 1.0.0-beta6 fails -- file_path column too long

[msaffitz]

Search before asking

• I had searched in the issues and found no similar issues.

What happened

Attempted to migrate the DB to 1.0.0-beta6. Upon migration, I get an error, below. Using mysql as DB.

2024-04-29 11:17:08 time="2024-04-29 18:17:08" level=info msg="\x1b[31;1m/app/impls/dalgorm/dalgorm.go:146 \x1b[35;1mError 1406 (22001): Data too long for column 'file_path' at row 2836\n\x1b[0m\x1b[33m[501.325ms] \x1b[34;1m[rows:0]\x1b[0m ALTER TABLE commit_files MODIFY COLUMN file_path VARBINARY(255);"

What do you expect to happen

Migration successfully completes.

How to reproduce

Attempted DB migration, JIRA and GitHub are source systems.

Anything else

No response

Version

v1.0.0-beta6

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[Startrekzky]

Did you collect some files with paths longer than varchar 255?

[msaffitz]

Yes @Startrekzky -- we have files in GitHub whose path + name are longer than 255 characters.

I'm happy to do a PR, but am not sure if the existing migration should be updated or needs to be a new migration? (if it's a new migration, do they get applied sequentially, or will the new one preclude the existing one that's breaking).

[Startrekzky]

Perhaps @klesh could help here.

[abeizn]

@msaffitz It takes effect in version v1.0.0-beta7.

[msaffitz]

@msaffitz It takes effect in version v1.0.0-beta7.

thanks @abeizn . I'm still seeing this on beta7:

| time="2024-05-10 22:34:10" level=info msg="\x1b[31;1m/app/impls/dalgorm/dalgorm.go:146 \x1b[35;1mError 1406 (22001): Data too long for column 'file_path' at row 2836\n\x1b[0m\x1b[33m[91.670ms] \x1b[34;1m[rows:0]\x1b[0m ALTER TABLE commit_files MODIFY COLUMN file_path VARBINARY(255);"

does it apply the migrations in order? (i.e. is it trying to first set to 255 and then apply the change to 1024? is there a way to skip the intermediate migration?

thanks again!

[msaffitz]

(looks like I was able to bypass it by manually adding an entry for the bad migration in the migration history table.

thanks again!