[Refactor][MySQL] Update variable type of column "component" on various tables

[rgcouto]

What and why to refactor

I've encountered an issue with running SonarQube Cloud analysis where the task would fail consistently due to the component column being too small on certain tables.

The error I'd see on logs was:

time="2025-06-18 08:32:04" level=error msg=" [pipeline service] [pipeline #8] [task #78] subtask convertIssueCodeBlocks ended unexpectedly\n\tWraps: (2) error adding result to batch (500)\n\tWraps: (3) Error 1406 (22001): Data too long for column 'component' at row 95 (500)\n\tWraps: (4) Error 1406 (22001): Data too long for column 'component' at row 95\n\tError types: (1) *hintdetail.withDetail (2) *hintdetail.withDetail (3) *hintdetail.withDetail (4) *mysql.MySQLError"

This error would lead to a failed analysis with consequently failing everything else on that Blueprint pipeline.

Describe the solution you'd like

I've figured out that changing the type of the component column on the database on tables cq_issue_code_blocks and _tool_sonarqube_issue_code_blocks, to varchar(500) did the trick. There might be other tables where this could also be applicable, probably.

If you find this useful I think it would be a good improvement.

[klesh]

Which version is it?

[rgcouto]

Which version is it?

I've used this version: v1.0.2-beta9

[klesh]

I see. There are two possible options:

1. Increase the length of the field, or change its type to TEXT.
2. Truncate the value before saving it to the database.

Which approach makes more sense to you?

[rgcouto]

I've tried to change to TEXT, but there was one of the tables where the field is part of an index and triggered an error when I tried to change it and thus had to change it to VARCHAR(500).

[klesh]

I see, I think option 2 is makes more sense in this case.