Data too long for 'mailto'

This patch throw an error:

WD php: PDOException: SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes: CREATE TABLE {mail_logger} (                                    [error]
`mlid` INT unsigned NOT NULL auto_increment COMMENT 'Mail Logger entry ID', 
`mailkey` VARCHAR(255) NOT NULL COMMENT 'a key identifying the mail type', 
`mailto` VARCHAR(2047) NOT NULL COMMENT 'to whom this mail is going', 
`subject` VARCHAR(255) NOT NULL COMMENT 'Mail subject', 
`body` LONGTEXT NOT NULL COMMENT 'Body text of the mail', 
`mailfrom` VARCHAR(255) NOT NULL COMMENT 'the FROM email address', 
`headers` LONGTEXT NOT NULL COMMENT 'Headers of the outgoing mail', 
`date_sent` INT unsigned NOT NULL COMMENT 'Mail Logger entry ID', 
`language` VARCHAR(20) NOT NULL COMMENT 'Language code', 
PRIMARY KEY (`mlid`), 
INDEX `mailto` (`mailto`), 
INDEX `mailfrom` (`mailfrom`), 
INDEX `subject` (`subject`(20)), 
INDEX `date_sent` (`date_sent`), 
INDEX `language` (`language`)
) ENGINE = InnoDB DEFAULT CHARACTER SET utf8 COMMENT 'Mail Logger table stores outgoing mails'; Array
(
)
 in db_create_table() (line 2720 of /home/[...]/includes/database/database.inc).

@NancyDru 5.6.26

according to http://dev.mysql.com/doc/refman/5.6/en/innodb-restrictions.html

to increase index key size it's needed a specific configuration
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 13.1.12, “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.

(also for mysql 5.7)

It works, many thanks!

This does not seem to solve my problem.

On a site with 1.1 installed i upgraded to revision 779b3d30426e573d9779fbef40543837dbbba830 and executed updates via updates.php. This is what i get:

Failed: PDOException: SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes: ALTER TABLE {mail_logger} CHANGE `mailto` `mailto` VARCHAR(2047) NOT NULL COMMENT 'to whom this mail is going'; Array ( ) in db_change_field() (line 3020 of /public/includes/database/database.inc).

I'm on:
branch 7.x-1.x
779b3d30426e573d9779fbef40543837dbbba830

I seem to be seeing this same issue with 7.x-1.3:

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes: ALTER TABLE {mail_logger} CHANGE `mailto` `mailto` VARCHAR(2047) NOT NULL COMMENT 'to whom this mail is going'; Array ( ) in db_change_field() (line 3020 of /home/ttivps/public_html/includes/database/database.inc).

Is there some way I can debug this? MySQL version: 5.6.29-log

Same error is displayed when I run update.php.
MySQL 5.6.28

also getting an error with mysql 5.6.28

Syntax error or access violation: 1071 Specified key was too long; max key length is 1000 bytes: ALTER TABLE {mail_logger} CHANGE `mailto` `mailto` VARCHAR(2047) NOT NULL COMMENT 'to whom this mail is going';

what's peculiar is that running that same query via drush sql-query works. running db_change_field() from a script fails.

the difference seems to be the value of the variable sql_mode - when the query is run from the script, the value is

REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER

STRICT_TRANS_TABLES seems to be the culprit. setting that explicitly before running the ALTER TABLE query causes the error.

http://dev.mysql.com/doc/refman/5.6/en/sql-mode.html
http://dev.mysql.com/doc/refman/5.6/en/sql-mode.html#sql-mode-strict

i changed the sql_mode variable in the install hook and that worked for me. the mysql doc link about strict sql mode says that it didn't used to generate an error, i think. it also implies that without the error it would just fail silently, i think, which isn't great.

#23 / #24 fixed the problem for me with MySQL 5.6.29.