Constraint name is too long
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona Toolkit moved to https://jira.percona.com/projects/PT |
Fix Released
|
Medium
|
Carlos Salguero |
Bug Description
pt-online-
It's happening in the latest version 2.2.15.
Example output (made with `--dry-run` option):
Error creating new table: DBD::mysql::db do failed: Identifier name '_suresc_
`id` int(11) NOT NULL AUTO_INCREMENT,
`syn_id` int(11) DEFAULT NULL,
`pkg_product_id` varchar(11) COLLATE utf8_unicode_ci NOT NULL,
`status` int(11) NOT NULL,
`relative_cost` int(11) DEFAULT NULL,
`created_at` datetime NOT NULL,
`updated_at` datetime NOT NULL,
`formulary_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
KEY `surescripts_
KEY `surescripts_
KEY `surescripts_
CONSTRAINT `_suresc_
) ENGINE=InnoDB AUTO_INCREMENT=
I realize that the FK name is too long, but it's generated automatically by our software framework, so we don't have any control over it.
It might be a better idea to use UUIDs or something similar to generate new constraint names.
tags: | added: pt144 |
Changed in percona-toolkit: | |
status: | Fix Committed → Fix Released |
pt-table-checksum has always had this behavior. In this latest version it is improved because it alternates adding and subtracting
Using an UUID or similar would guarantee uniqueness and has been considered before.
The ugly part is that we'd have to arbitrarily truncate very long names.
This is really a very border case. A dynamically generated name that happens to be exactly the max length allowed!
But I appreciate it's affecting you.
A random id would be the ultimate solution to name conflict, at the cost of readability perhaps.