Problem/Motivation

Over in #1314214: MySQL driver does not support full UTF-8 (emojis, asian symbols, mathematical symbols), indexes that were going to exceed the maximum length allowed were automatically truncated. This change was only applied to normal indexes though, and not unique or primary keys.

Proposed resolution

Shorten primary and unique keys as needed.

Remaining tasks

User interface changes

API changes

Data model changes

Files: 
CommentFileSizeAuthor
#1 shorten-all-indexes-2522098-01.patch1.92 KBjhedstrom
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 97,226 pass(es). View

Comments

jhedstrom’s picture

Status: Active » Needs review
FileSize
1.92 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 97,226 pass(es). View

First attempt. The code could probably be better refactored so this is more elegant.

morgantocker’s picture

Be careful with this. Shortening a UNIQUE index means that only part of the constraint is applied (from left to right). This might be OK for most cases, but input like URLs contain uniqueness very late in the string.

stefan.r’s picture

This was actually as designed. We can't just shorten a primary key / unique index at runtime without changing behavior (strings that start with the same 191 characters will give an error) whereas for a regular index there is no real impact whether it's 191 characters long or 255 characters long.

We created a change record that explicitly states this: https://www.drupal.org/node/2510940

So if we we were to change anything, wouldn't it have to be the length of the field and not that of the primary key/unique index?

And in such case it'd be confusing to have 255 in the schema but 191 in the database, so I think this should just keep throwing an error on table creation, but maybe we can catch the "Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes" error and gives a few more pointers instead or link to the change record?

stefan.r’s picture

Status: Needs review » Needs work
jhedstrom’s picture

re #2 good catch. This is a first attempt to fix issues over in the Head 2 Head module for testing updates, not sure if it's the best idea or not.

#2514860: Add db dumps of each beta for testing purposes

jhedstrom’s picture

Cross post on that. #3 makes total sense as well, and since this isn't necessarily something people will run into, this might be won't fix, or go with the try/catch for better DX.

jhedstrom’s picture

I added #2522120: DbDumpCommand should add collation information to the generated script as a better fix for the more immediate issue with testing update paths.

morgantocker’s picture

For MySQL version context (also mentioned in the other related issues):

The 767 bytes is a limitation in the _default_ configuration of MySQL. From 5.5+ it is possible to have a 3000 byte limit, but it requires changing settings Drupal can not expect users can change (innodb-file-format=barracuda, innodb-large-prefix=1).

The defaults for both of these settings change in MySQL 5.7, so any script to truncate indexes should not do this to an install of 5.7+ because this would offer an unneeded functionality regression.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.