[Bug][GitHub] Data too long for column 'production_pattern'

[jeffschaper]

Search before asking

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

What happened

I'm getting an error message related to the GitHub scope config production pattern.

Wraps: (2) Error 1406 (22001): Data too long for column 'production_pattern' at row 1
Error types: (1) *hintdetail.withDetail (2) *mysql.MySQLError

It appears to be the production_pattern field from the _tool_github_scope_configs table, which is a varchar(255) data type.

What do you expect to happen

The production_pattern field in the _tool_github_scope_configs table should allow for larger values to be stored.

How to reproduce

Try to store a value longer than 255 characters in the production_pattern field in the _tool_github_scope_configs table or in the GitHub scope config in the config ui (see screenshot below).

Anything else

This only happens when a value is bigger than 255 characters.

Version

v1.0.1

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

[dosubot]

The error you're encountering is due to the production_pattern field in the _tool_github_scope_configs table being defined as a varchar(255), which limits the length of the value you can store to 255 characters. To resolve this issue, you can consider increasing the size of the production_pattern field in the database schema to accommodate longer values. This would involve altering the table to change the column type to something like varchar(512) or text, depending on your needs.

Here's a general SQL command you might use to alter the column size:

ALTER TABLE _tool_github_scope_configs MODIFY production_pattern VARCHAR(512);

Make sure to back up your database before making schema changes, and test the changes in a development environment first to ensure they don't cause any unintended issues.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other}

[jeffschaper]

Thanks @dosu!

I'm hesitant to make this table altercation myself because I want to ensure it doesn't cause any unexpected problems if/when we decide to upgrade to a newer version of DevLake.

If the fix is made at the repo level, then I would be more confident the migration scripts would run as expected if/when we decide to upgrade to a newer version of DevLake.

[dosubot]

Would you like guidance on how to propose this change to the DevLake repository, or are you looking for alternative solutions that don't involve altering the database schema directly?

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other}