[MySQL] Deprecate automatically setting collation to {charset}_unicode_ci as it can produce invalid collations

[ruudk]

While working on doctrine/orm#9636 I noticed that the AbstractMySQLPlatform does something really weird.

When you define charset for the Table options, without defining the collation, it will automatically construct the collation like this:

dbal/src/Platforms/AbstractMySQLPlatform.php

Lines 459 to 462 in 719663b

	// Collation
	if (! isset($options['collation'])) {
	$options['collation'] = $options['charset'] . '_unicode_ci';
	}

This is naive, as it assumes that there is always a _unicode_ci for every given charset. For exampe, If I set the charset to ascii it tries to create ascii_unicode_ci which doesn't exist.

I think a deprecation should be triggered when charset is defined without specifying the collation. It teaches people to define both.

I also think that this is weird:

dbal/src/Platforms/AbstractMySQLPlatform.php

Lines 448 to 451 in 719663b

	// Charset
	if (! isset($options['charset'])) {
	$options['charset'] = 'utf8';
	}

It uses the default utf8 alias which points to utf8mb3 which is not compatible with UTF8. It should be utf8mb4. So maybe instead of setting this default, not do it, and or trigger a deprecation.

References:

• https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8.html

/cc @greg0ire

[morozov]

The defaults will be removed in 4.0 (#4644).

I think a deprecation should be triggered when charset is defined without specifying the collation. It teaches people to define both.

That's arguable. Since MySQL doesn't force specifying the collation alongside the charset, the DBAL shouldn't either.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.