Deprecate not specifying charset #5278
Conversation
greg0ire
force-pushed
the
deprecate-not-specifying-charset
branch
from
331138a
to
8b610e8
Compare
This is similar to an issue we have had on the ORM with identifier generator strategies: we default to some value of a setting, then something better comes out, and we get stuck with the deprecated setting for backward compatibility reasons. In this case, utf8 has been deprecated for years and should no longer be used according to the official documentation: https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8.html This kind of BC-break might be handled better by things such as Symfony Recipes because it is OK to do such BC breaks there since they only affect new projects.
greg0ire
force-pushed
the
deprecate-not-specifying-charset
branch
from
8b610e8
to
4f4edc4
Compare
|
I don't agree with this change: a The platform-aware schema comparison logic for MySQL is aware of the default table charset and collation and uses them to compare the explicit and implicit values on the columns. It doesn't do so for the table charset/collation (#4945) which also applies to other table "options" like |
| 'doctrine/dbal', | ||
| 'https://github.com/doctrine/dbal/pull/5278', | ||
| 'Omitting the charset option is deprecated, be explicit about it instead. We recommend using "utf8b4"' | ||
| ); | ||
| $options['charset'] = 'utf8'; |
There was a problem hiding this comment.
The charset and collation parameters are optional because they are not portable and are not required in the CREATE TABLE DDL.
@morozov ok, so although this is not the right way to handle the problem, you do admit there is an issue on this line, right? If the charset parameter is optional, why is there a default value here?
There was a problem hiding this comment.
you do admit there is an issue on this line, right?
Yes, it will be addressed by #4644.
If the charset parameter is optional, why is there a default value here?
I don't know. See #4644 (comment).
Follow up of #5277
This is similar to an issue we have had on the ORM with identifier
generator strategies: we default to some value of a setting, then
something better comes out, and we get stuck with the deprecated setting
for backward compatibility reasons.
In this case, utf8 has been deprecated for years and should no longer be
used according to the official documentation:
https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8.html
This kind of BC-break might be handled better by things such as Symfony
Recipes because it is OK to do such BC breaks there since they only
affect new projects.
Should we also do the same for
collation? I'm not sure, but there seems to be better collations than the default one.https://dev.mysql.com/blog-archive/new-collations-in-mysql-8-0-0/