I just opened BSP-6626 about this. I suspect you may not have fixed the issue completely.
The original intent here was to create an index on the COMMIT_REVISION column in the USER_COMMIT table.
However the following still occurs:
- The schema update still throws the error above when upgrading from 3.3.3 -> 3.4.4.
- Upgrade task 2806 carries out the conversion of column type from TEXT to VARCHAR
- Upgrade task 2806 doesn't appear to try and create the index after the conversion.
- This was verified in BSP-6626 by listing the indices that exist after the upgrade completes.
I believe a new upgrade task need to be added to create the index that runs some time after 2806.
Furthermore if the existing syntax for the index creation is used, a prefix of the default VARCHAR size of 255 will be used for the index, even though the column is specified by Bamboo to be VARCHAR(4000).
You might want to consider reducing the VARCHAR column size based on the following from the MySQL documentation
By default, an index key for a single-column index can be up to 767 bytes. The same length limit applies to any index key prefix. See Section 12.1.13, “CREATE INDEX Syntax”. For example, you might hit this limit with a column prefix index of more than 255 characters on a TEXT or VARCHAR column, assuming a UTF-8 character set and the maximum of 3 bytes for each character. When the innodb_large_prefix configuration option is enabled, this length limit is raised to 3072 bytes, for InnoDB tables that use the DYNAMIC and COMPRESSED row formats.When you attempt to specify an index prefix length longer than allowed, the length is silently reduced to the maximum length. This configuration option changes the error handling for some combinations of row format and prefix length longer than the maximum allowed. See innodb_large_prefix for details.
FWIW, I tested out a restart of Bamboo 3.4 after an initial upgrade and the index was created successfully as you suggested.