potiuk commented on a change in pull request #20102:
URL: https://github.com/apache/airflow/pull/20102#discussion_r763971233
##########
File path: docs/apache-airflow/howto/set-up-database.rst
##########
@@ -238,7 +238,7 @@ In the example below, a database ``airflow_db`` and user
with username ``airflo
.. code-block:: sql
- CREATE DATABASE airflow_db CHARACTER SET utf8 COLLATE utf8mb4_unicode_ci;
+ CREATE DATABASE airflow_db CHARACTER SET utf8 COLLATE utf8mb3_unicode_ci;
Review comment:
This is the correct fix. See the comment in the documentation. Even if
MySQL8 indeed aliases utf8 to utf8mb3 today they themselves explicitly warn
that this is going to change in the (near) future and that utf8mb3 is actually
- even today - deprecated:
> The utf8mb3 character set is deprecated and you should expect it to be
removed in a future MySQL release. Please use utf8mb4 instead. utf8 is
currently an alias for utf8mb3, but it is now deprecated as such, and utf8 is
expected subsequently to become a reference to utf8mb4. Beginning with MySQL
8.0.28, utf8mb3 is also displayed in place of utf8 in columns of Information
Schema tables, and in the output of SQL SHOW statements.
> To avoid ambiguity about the meaning of utf8, consider specifying utf8mb4
explicitly for character set references.
And yes encoding in MYSQL is a mess. Always has been. And with comments like
that where on one hand software behaves one way when `utf8` is specified but
soon, it will start behaving differently when the same `utf8` is specified in
the future it makes it even more confusing,
Let's be explicit and use `utf8mb4` everywhere now in our examples - we
already in Airflow automatically use `utf8mb3` collation for the IDs that
otherwise would create too big indexes (yeah. you read it right usin utf8mb4
blows up the indexes so much that they extend the limit of the indexes.
Did I say what's my sentiment towards MySQL ? Yep I did. I won't repeat it
again but you might figure out :)
##########
File path: docs/apache-airflow/howto/set-up-database.rst
##########
@@ -238,7 +238,7 @@ In the example below, a database ``airflow_db`` and user
with username ``airflo
.. code-block:: sql
- CREATE DATABASE airflow_db CHARACTER SET utf8 COLLATE utf8mb4_unicode_ci;
+ CREATE DATABASE airflow_db CHARACTER SET utf8 COLLATE utf8mb3_unicode_ci;
Review comment:
This is the correct fix. See the comment in the documentation. Even if
MySQL8 indeed aliases utf8 to utf8mb3 today they themselves explicitly warn
that this is going to change in the (near) future and that utf8mb3 is actually
- even today - deprecated:
> The utf8mb3 character set is deprecated and you should expect it to be
removed in a future MySQL release. Please use utf8mb4 instead. utf8 is
currently an alias for utf8mb3, but it is now deprecated as such, and utf8 is
expected subsequently to become a reference to utf8mb4. Beginning with MySQL
8.0.28, utf8mb3 is also displayed in place of utf8 in columns of Information
Schema tables, and in the output of SQL SHOW statements.
> To avoid ambiguity about the meaning of utf8, consider specifying utf8mb4
explicitly for character set references.
And yes encoding in MYSQL is a mess. Always has been. And with comments like
that where on one hand software behaves one way when `utf8` is specified but
soon, it will start behaving differently when the same `utf8` is specified in
the future it makes it even more confusing,
Let's be explicit and use `utf8mb4` everywhere now in our examples - we
already in Airflow automatically use `utf8mb3` collation for the IDs that
otherwise would create too big indexes (yeah. you read it right usin utf8mb4
blows up the indexes so much that they extend the limit of the indexes).
Did I say what's my sentiment towards MySQL ? Yep I did. I won't repeat it
again but you might figure out :)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
