Problem/Motivation
When it tries to create the source table fails with this error.
SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key
was too long; max key length is 3072 bytes: CREATE TABLE
{migrate_map_migrate_cases} (
`source_ids_hash` VARCHAR(64) NOT NULL COMMENT 'Hash of source
ids. Used as primary key',
`sourceid1` VARCHAR(32) CHARACTER SET ascii COLLATE ascii_general_ci
NOT NULL,
`sourceid2` INT NOT NULL,
`sourceid3` VARCHAR(255) NOT NULL,
`sourceid4` INT NOT NULL,
`sourceid5` INT NOT NULL,
`sourceid6` INT NOT NULL,
`sourceid7` VARCHAR(255) NOT NULL,
`sourceid8` DECIMAL(10, 2) NOT NULL,
`sourceid9` VARCHAR(255) NOT NULL,
`sourceid10` VARCHAR(255) NOT NULL,
`source_row_status` TINYINT unsigned NOT NULL DEFAULT 0 COMMENT
'Indicates current status of the source row',
`rollback_action` TINYINT unsigned NOT NULL DEFAULT 0 COMMENT
'Flag indicating what to do for this item on rollback',
`last_imported` INT unsigned NOT NULL DEFAULT 0 COMMENT 'UNIX
timestamp of the last time this row was imported',
`hash` VARCHAR(64) NULL DEFAULT NULL COMMENT 'Hash of source row
data, for detecting changes',
PRIMARY KEY (`source_ids_hash`),
INDEX `source` (`sourceid1`, `sourceid2`, `sourceid3`(191),
`sourceid4`, `sourceid5`, `sourceid6`, `sourceid7`(191), `sourceid8`,
`sourceid9`(191), `sourceid10`(191))
) ENGINE = InnoDB DEFAULT CHARACTER SET utf8mb4 COMMENT
'Mappings from source identifier value(s) to
destination…';
Proposed resolution
I temporally fixed it removing the index but that means that everything will be slower, I need a better solution here.
Maybe it has something to be with the fact that I use InnoDB but this must work with this engine to, so we have to fix it.
Comments
Comment #2
mikeryanA consequence of #2843595: Add indexes to migrate_map_* tables, if your source IDs combined are too big to index in MySQL InnoDB.
I have to ask - why do you have 10 source ID fields? Do you really need 10 fields to uniquely identify each row of source data?
Comment #3
mikeryanComment #4
edurenye CreditAttribution: edurenye as a volunteer commentedMy bad, sorry. No, I don't need that many keys, I just thought I was defining the data types of the columns not the keys.
I guess it's difficult that anybody might need that many keys, so I close it.
Thank you very much.
Comment #5
mglamanThis causes issues when there are 5 keys, even. Such as a taxonomy term name, where keys matter to ensure parent mapping.
This is fine:
This throws error over length
Is there a way to somehow cause the \Drupal\migrate\Plugin\migrate\id_map\Sql::ensureTables to use MyISAM (if that'll solve the problem, even?)
EDIT:
Nevermind. MyISAM limit is 1,000.
Comment #6
mglamanSince I commented I figure I'd share my solution.
ID Map plugin
Migration
Comment #7
2dareis2do CreditAttribution: 2dareis2do commentedHmm, I am getting similar issue. I have posted link here https://www.drupal.org/project/drupal/issues/3044897
The import starts ok then seems to choke, where the source id is around 300 characters. I don't really understand why this is as from what I can see the source id is hashed anyway!? If someone could explain what is happening during the import and what sourceid1 is I would love to know.
Currently testing on mariadb:10.1-2.3.5
Comment #8
2dareis2do CreditAttribution: 2dareis2do commentedok switching unique field to be the shorter link field and this migrates/imports the feed with any issues. Using GUID definitely as the unique field definitely seems to create problems in mysql.
This is the feed I was using.
https://news.google.com/rss/search?q=streatham&hl=en-GB&gl=UK&ceid=GB:en