Re: Issue migrating from MySQL 5.7 to 8.0.20: Index/candidate part #0 for xyz already set


Page bloom
 
Edited

This paragraph from the "Changes in MySQL 8.0.16" page (https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-16.html) looks interesting:

Incompatible Change: In MySQL 5.7, specifying a FOREIGN KEY definition for an InnoDB table without a CONSTRAINT symbol clause, or specifying the CONSTRAINT keyword without a symbol, causes InnoDB to use a generated constraint name. That behavior changed in MySQL 8.0, with InnoDB using the FOREIGN KEY index_name value instead of a generated name. Because constraint names must be unique per schema (database), the change caused errors due to foreign key index names that were not unique per schema. To avoid such errors, the new constraint naming behavior has been reverted, and InnoDB once again uses a generated constraint name.

For consistency with InnoDB, the NDB storage engine now uses a generated constraint name if the CONSTRAINT symbol clause is not specified, or the CONSTRAINT keyword is specified without a symbol. In NDB releases based on MySQL 5.7 and earlier MySQL 8.0 releases, NDB used the FOREIGN KEY index_name value.

The changes described above may introduce incompatibilities for applications that depend on the previous foreign key constraint naming behavior. (Bug #29173134)


Although, as we're using InnoDB and not NDB then it appears as though they've reverted the new 8.0 behaviour back to 5.7 behaviour as of 8.0.16 - confused :~]

Join main@datanucleus.groups.io to automatically receive all group messages.