Recommend a better charset by default

[greg0ire]

In MySQL, utf8 is an alias for utf8mb3, which is not really utf8 since
it only uses 3 bytes.
As a result utf8 has been deprecated and should not be used.
See https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8.html

Disclaimer: I am by no means a MySQL specialist, and find it a bit surprising that this hasn't been changed for such a long time (it was introduced in 59e17b5 , 6 years ago).

Note that from my understanding, this will not affect the charset of new tables.

EDIT: it looks like I understood wrong:

dbal/src/Schema/AbstractSchemaManager.php

Lines 1256 to 1258 in 7ac3095

	if (! isset($params['defaultTableOptions']['charset']) && isset($params['charset'])) {
	$params['defaultTableOptions']['charset'] = $params['charset'];
	}

Introduced in #3003

[morozov]

Regarding the documentation, why does the DBAL even have to recommend one specific charset? Since it's just an example, instead of using something that may look like a recommendation, could it use something exotic to make sure it's not used as is? Alternatively, we could just remove the "charset" parameter from the URL. The documented value is specific to MySQL and specific MySQL versions while there are other supported drivers and connection parameters.

Regarding the code, what does this code do? Why does it use the connection parameter in the schema definition?

[greg0ire]

Regarding the code, what does this code do? Why does it use the connection parameter in the schema definition?

I'm wondering that too. #3003 does not come with an explanation besides

If the database is utf8mb4, tables should be utf8mb4 by default.

or with documentation, but I'll concede it would make sense to default to consistent charsets.

[greg0ire]

I switched to an invalid charset, that way users will be forced to read the docs to pick the charset they think is correct. Picking an exotic charset might result in people just using it because they copy/paste without understanding.

[morozov]

I switched to an invalid charset [...]

That's odd because up until now, the URL described a realistic setup while now it doesn't. The bar doesn't look better than utf8 to me.

Picking an exotic charset might result in people just using it because they copy/paste without understanding.

Is it the problem we're trying to address there? The bar is prone to this error as well.

Personally, I wouldn't make this change just for the sake of a change. The documentation illustrates the use of connection parameters in the URL from the syntax perspective. It doesn't describe all supported parameters, their support by the drivers, and the recommended values. It's already good enough.

[derrabus]

I switched to an invalid charset [...]

That's odd because up until now, the URL described a realistic setup while now it doesn't. The bar doesn't look better than utf8 to me.

In a realistic setup, please let's not use a deprecated charset setting with surprising behavior. Let's use utf8mb4 in this example. Even if someone C&Ps the URL from the documentation, they at least copied a sane configuration.

[morozov]

Then I would remove the "with the charset set to UTF-8". Otherwise, it makes the DBAL provide a solution to the problem that should be solved using the MySQL documentation.

[derrabus]

Then I would remove the "with the charset set to UTF-8".

Let's rephrase, to make it clear we're not talking about the concept of character sets but about passing an option as-is to the driver:

For example, to connect to a "foo" MySQL DB using the ``pdo_mysql``
driver on localhost port 4486 with the "charset" option set to "utf8mb4",
you would use the following URL::