# Ticket 18392 and MySQL utf8mb4 **URL:** \ **Category:** Django Internals\ **Created:** [September 19, 2024, 3:59pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916 "2024-09-19T15:59:03Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![benc](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/benc/32/16767_2.png) [@benc](https://forum.djangoproject.com/u/benc)\ **Post date:** [September 19, 2024, 3:59pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/1 "2024-09-19T15:59:03Z")
Django’s minimum required version of MySQL is [8.0.11](https://docs.djangoproject.com/en/dev/ref/databases/#mysql-notes). Since MySQL 8.0, the utf8mb4 charset has been [recommended](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html), instead of the old utf8/utf8mb3, which they have deprecated. Currently, Django [defaults](https://github.com/django/django/blob/main/django/db/backends/mysql/base.py#L218) to using the deprecated “utf8”/“utf8mb3” character set. If a user wants to use a different character set, they can add the “charset” and “collation” options to their DATABASES configuration. What do you think of changing Django defaults to “utf8mb4” for MySQL, with notes for the users that they can use the DATABASES options to stay on “utf8mb3” if they have a legacy database that isn’t fully ready for “utf8mb4”? (See [the ticket](https://code.djangoproject.com/ticket/18392) for past discussion.) ---
**Author:** ![collinanderson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/collinanderson/32/22001_2.png) [@collinanderson](https://forum.djangoproject.com/u/collinanderson)\ **Post date:** [September 19, 2024, 4:18pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/2 "2024-09-19T16:18:06Z")
Wow. Yes. I always assumed that it was mysql that was defaulting to “utf8”, not Django. I have `"OPTIONS": {"charset": "utf8mb4"},` set in all of my database settings and I 100% agree this should be the default in Django, otherwise you get emoji issues. With “utf8” aka “utf8mb3” being deprecated I think it makes it even more clear. As far as I know the old 191 index-length concern is no longer an issue in modern MySQL versions, which I think would have been the main reason for keeping “utf8” as the default, (besides backward compatibility). ---
**Author:** ![claudep](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/claudep/32/5377_2.png) [@claudep](https://forum.djangoproject.com/u/claudep)\ **Post date:** [September 19, 2024, 6:48pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/3 "2024-09-19T18:48:09Z")
I also think that at some point we’ll have to go forward and change the default. One method would be to change the default in the next Django version and prominently document it. Another possible option could be passing through an (accelerated?) deprecation step, by obtaining the default database charset and warn projects to set an explicit `'OPTIONS': {'charset': 'utf8'}` if they want to keep using the legacy encoding, as the default will change in the next Django version. ---
**Author:** ![benc](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/benc/32/16767_2.png) [@benc](https://forum.djangoproject.com/u/benc)\ **Post date:** [September 23, 2024, 2:15pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/4 "2024-09-23T14:15:13Z")
Thanks. I think the index length could still be limited if someone switched to utf8mb4, but kept the old row format. I would tend to just list that in the documentation and suggest they stay on the old utf8mb3 if they can’t update the row format. ---
**Author:** ![benc](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/benc/32/16767_2.png) [@benc](https://forum.djangoproject.com/u/benc)\ **Post date:** [September 23, 2024, 2:18pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/5 "2024-09-23T14:18:40Z")
Thanks. My preference would be to change the default and prominently document it, but if we need to go through a deprecation step, we could. If we do a deprecation step, I wonder if we could just mark the default-utf8mb3 as deprecated, without adding code to check the database that django is connecting to. ---
**Author:** ![claudep](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/claudep/32/5377_2.png) [@claudep](https://forum.djangoproject.com/u/claudep)\ **Post date:** [September 23, 2024, 9:19pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/6 "2024-09-23T21:19:18Z")
Maybe, but I’m not certain it’s possible to determine the database collation based on the connection setting only. A bit tricky (that’s why the ticket is currently rotting). Breaking the compatibility is really the simplest way, but is not very in line with the traditional compatibility policy of Django. ---
**Author:** ![benc](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/benc/32/16767_2.png) [@benc](https://forum.djangoproject.com/u/benc)\ **Post date:** [September 24, 2024, 12:48pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/7 "2024-09-24T12:48:31Z")
I guess since all a user has to do to stay on utf8mb3 is put the charset & collation in the databases options, I don’t think it’s too bad of an incompatibility. And, the change is in line with what MySQL is doing - MySQL has deprecated the current Django default, so currently Django is defaulting to a deprecated (and many would argue, a broken) character set. And, the current default is already causing problems - users like @collinanderson who want real UTF8 currently have to know about the issue and take an extra step to support it. @claudep Do you think a Steering Council decision would be required to change the default? ---
**Author:** ![claudep](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/claudep/32/5377_2.png) [@claudep](https://forum.djangoproject.com/u/claudep)\ **Post date:** [September 24, 2024, 5:05pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/8 "2024-09-24T17:05:55Z")
> Do you think a Steering Council decision would be required to change the default? Not necessarily. The idea of a forum thread is to be able to collect several opinions and see if some clear path emerges. For example, I would love to get the opinion of @adamchainz, as the maintainer of django-mysql. ---
**Author:** ![apollo13](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/apollo13/32/30_2.png) [@apollo13](https://forum.djangoproject.com/u/apollo13)\ **Post date:** [September 24, 2024, 5:24pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/9 "2024-09-24T17:24:24Z")
> [@benc](#): > > I guess since all a user has to do to stay on utf8mb3 is put the charset & collation in the databases options, I don’t think it’s too bad of an incompatibility. We saw how well that went with the storage changes where users lost their files because they didn’t update the configuration. On the plusside I don’t think that changing to utf8mb4 as a default would result in loosing data. But it can be really annoying if the default gets changed and a new table gets created with utf8mb4 and all of a sudden you can no longer join tables because the charsets don’t match etc… All in all it would be great to change the default. ---
**Author:** ![benc](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/benc/32/16767_2.png) [@benc](https://forum.djangoproject.com/u/benc)\ **Post date:** [October 2, 2024, 12:53pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/10 "2024-10-02T12:53:36Z")
Any more thoughts on this issue? @adamchainz @nessita @sarahboyce others? ---
**Author:** ![benc](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/benc/32/16767_2.png) [@benc](https://forum.djangoproject.com/u/benc)\ **Post date:** [October 17, 2024, 9:14pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/11 "2024-10-17T21:14:19Z")
Here’s a [sample PR](https://github.com/django/django/pull/18689) for the change. ---
**Author:** ![nessita](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/nessita/32/12194_2.png) [@nessita](https://forum.djangoproject.com/u/nessita)\ **Post date:** [October 21, 2024, 1:31pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/12 "2024-10-21T13:31:45Z")
Hello @benc, thank you for your patience. From my reading of the linked docs, I think your proposal makes sense. As a very isolated reference point, I have asked the Grafana On Call team (which use MySQL for their setup) which encoding do they use and [they confirmed they use `utf8mb4` by default](https://github.com/grafana/oncall/blob/dev/engine/settings/base.py#L185). I would like some certainty that changing the default does not loose data as Florian (@apollo13) suggest: with that confirmation, I think it makes sense to change the default. @charettes would you have an opinion on this proposal? ---
**Author:** ![benc](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/benc/32/16767_2.png) [@benc](https://forum.djangoproject.com/u/benc)\ **Post date:** [October 23, 2024, 2:42pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/13 "2024-10-23T14:42:14Z")
Here’s one thing that could happen if we change the default: if a user has a utf8 collation (eg. “utf8mb3\_general\_ci”), but is using the default django charset (ie. “utf8”), then if we change the default django charset to “utf8mb4”, an exception is thrown: “COLLATION ‘utf8mb3\_general\_ci’ is not valid for CHARACTER SET ‘utf8mb4’” To fix this, the user would need to explicitly set the charset to “utf8mb3”, instead of depending on the default. ---
**Author:** ![charettes](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/charettes/32/27_2.png) [@charettes](https://forum.djangoproject.com/u/charettes)\ **Post date:** [October 24, 2024, 2:34am UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/14 "2024-10-24T02:34:04Z")
From my understanding setting [the `charset` option of the `mysqlclient` library](https://mysqlclient.readthedocs.io/user_guide.html#functions-and-attributes) results in [the `mysql_set_character_set` C call](https://github.com/PyMySQL/mysqlclient/blob/6eb6c2f8796fdf16c5356beb4cb888da4e46be09/src/MySQLdb/_mysql.c#L1620) which I assume is the equivalent of [the `SET CHARACTER SET` statement](https://dev.mysql.com/doc/refman/8.0/en/set-character-set.html) which _maps all strings sent between the server and the current client with the given mapping_ by setting three session system variables - [`character_set_client`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_character_set_client) - [`character_set_results`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_character_set_results) - [`character_set_connection`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_character_set_connection) to the value of [`character_set_database`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_character_set_database). * * * Assuming the above is correct if we look at these three settings in isolation in terms of what the impact of moving from `utf8` to `utf8mb4` would have. Changing [`character_set_client`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_character_set_client) seems like it will only make things more permissive as it will allow strings literals requiring 4-bytes encoding to be transmitted from the client to the server. Ultimately if the table has columns defined with a charset of `utf8mb3` they will still be disallowed to store some bytes sequences but that’s already the case today unless I’m missing something. Changing [`character_set_results`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_character_set_results) also seems like a non-issue because `utf8mb4` is a superset of `utf8mb3` so Python will be able to decode both using the equivalent of `bytes.decode('utf8')` when transmitted from the server. Lastly it has no direct effect on [`character_set_connection`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_character_set_connection) since it sets it to a server defined value which passing `utf8` also did. * * * To summarize I don’t think that changing `charset` like it’s proposed here poses risks regarding indexing or interoperability at querying time as `SET CHARSET` won’t affect the default character set used to define entities storing _text_ (that’s something controlled by [`character_set_database`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_character_set_database) which is inherited from [`character_set_server`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_character_set_server)). In other words, from my understanding, all this configuration does is increase interoperability for string literals exchange between the client and the server and has no effect on [`character_set_database`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_character_set_database) which [is implicitly used for tables, columns, and indices creation](https://dev.mysql.com/doc/refman/8.0/en/charset-table.html). > Otherwise (neither `CHARACTER SET` nor `COLLATE` is specified), the database character set and collation are used. The problem of tables created with `utf8mb3` columns and indices (they can’t store characters like emojis) and the limitations of `utf8mb4` with regards to indexing (limited to 191 characters) has little to do with this particular flag and more with their MySQL server configuration as Django never explicitly specified which charset and collations should be used on schema changes (it always defaulted to the configured database character set which `SET CHARSET` has no effect on). If you’d like a visual confirmation of that you can refer to [this MySQL 8.0.36 fiddle](https://dbfiddle.uk/mRHqe0uP) or the > **Fiddle** > > ```auto > select version(); > > ``` > > | version() | > | --- | > | 8.0.36 | > > ```auto > SHOW VARIABLES LIKE 'character_set%'; > > ``` > > | Variable\_name | Value | > | --- | --- | > | character\_set\_client | utf8mb4 | > | character\_set\_connection | utf8mb4 | > | character\_set\_database | utf8mb4 | > | character\_set\_filesystem | binary | > | character\_set\_results | utf8mb4 | > | character\_set\_server | utf8mb4 | > | character\_set\_system | utf8mb3 | > | character\_sets\_dir | /usr/share/mysql-8.0/charsets/ | > > ```auto > SELECT '🐬'; > > ``` > > | ? | > | --- | > | 🐬 | > > ```auto > CREATE TABLE before_table (field text); > > ``` > > ```auto > SHOW CREATE TABLE before_table; > > ``` > > | Table | Create Table | > | --- | --- | > | before\_table | CREATE TABLE `before_table` ( > `field` text > ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4\_0900\_ai\_ci | > > ```auto > INSERT INTO before_table (field) VALUES ('🐬'); > > ``` > > ```auto > SELECT * FROM before_table; > > ``` > > | field | > | --- | > | 🐬 | > > ```auto > SET CHARSET 'utf8'; -- This is currently what Django does > > ``` > > ```auto > SHOW VARIABLES LIKE 'character_set%'; > > ``` > > | Variable\_name | Value | > | --- | --- | > | character\_set\_client | utf8mb3 | > | character\_set\_connection | utf8mb4 | > | character\_set\_database | utf8mb4 | > | character\_set\_filesystem | binary | > | character\_set\_results | utf8mb3 | > | character\_set\_server | utf8mb4 | > | character\_set\_system | utf8mb3 | > | character\_sets\_dir | /usr/share/mysql-8.0/charsets/ | > > ```auto > SELECT '🐬'; > > ``` > > | ??? | > | --- | > | ??? | > > ```auto > CREATE TABLE after_table (field text); > > ``` > > ```auto > SHOW CREATE TABLE after_table; > > ``` > > | Table | Create Table | > | --- | --- | > | after\_table | CREATE TABLE `after_table` ( > `field` text > ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4\_0900\_ai\_ci | > > ```auto > INSERT INTO after_table (field) VALUES ('🐬'); > > ``` > > ```auto > SELECT * FROM after_table; > > ``` > > | field | > | --- | > | ??? | > > [fiddle](https://dbfiddle.uk/zXHIIOXX) The only _risk_ this change poses is that passing unicode characters literals that are 4-bytes wide to compare them against `utf8mb3` columns will now loudly error out [instead of silently corrupting them](https://dbfiddle.uk/AWuBnJp-). I feel like it could be valuable for users to be made aware of this problem and the need to rebuild their tables with a more adequate charset than to keep hiding this problem from them. ---
**Author:** ![nessita](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/nessita/32/12194_2.png) [@nessita](https://forum.djangoproject.com/u/nessita)\ **Post date:** [November 14, 2024, 6:04pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/15 "2024-11-14T18:04:17Z")
Thank you @charettes, your reply is very educational and complete. I deeply appreciate the time you invested in writing it! I’ll circle back to @benc’s PR. ---
**Author:** ![benc](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/benc/32/16767_2.png) [@benc](https://forum.djangoproject.com/u/benc)\ **Post date:** [November 18, 2024, 4:33pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/16 "2024-11-18T16:33:50Z")
Thank you all - the default has now been changed to “utf8mb4”. ---
**Author:** ![nessita](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/nessita/32/12194_2.png) [@nessita](https://forum.djangoproject.com/u/nessita)\ **Post date:** [November 27, 2024, 5:59pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/17 "2024-11-27T17:59:44Z")
@benc Hi! I’ve noticed an error in our Jenkins CI instance, for MariaDB and Python 3.12, where we get the following error: `django.db.utils.OperationalError: (1918, "Encountered illegal value 'μg/mL' when converting to latin1")` This definitely seems related to this change so I was hoping if you would have some time to debug and evaluate. - CI run: [django-mariadb » mysql,mariadb,python3.12 mysql,mariadb,python3.12 Console [Jenkins]](https://djangoci.com/job/django-mariadb/1440/database=mysql,label=mariadb,python=python3.12/console) - Traceback for posterity: ```auto Synchronizing apps without migrations: Creating tables... Creating table django_content_type Creating table auth_permission ... Creating table constraints_product Traceback (most recent call last): File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/django/db/backends/utils.py", line 103, in _execute return self.cursor.execute(sql) ^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/django/db/backends/mysql/base.py", line 76, in execute return self.cursor.execute(query, args) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/tests/.env/lib/python3.12/site-packages/MySQLdb/cursors.py", line 179, in execute res = self._query(mogrified_query) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/tests/.env/lib/python3.12/site-packages/MySQLdb/cursors.py", line 330, in _query db.query(q) File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/tests/.env/lib/python3.12/site-packages/MySQLdb/connections.py", line 265, in query _mysql.connection.query(self, query) MySQLdb.OperationalError: (1918, "Encountered illegal value 'μg/mL' when converting to latin1") The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/tests/./runtests.py", line 787, in failures = django_tests( ^^^^^^^^^^^^^ File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/tests/./runtests.py", line 425, in django_tests failures = test_runner.run_tests(test_labels) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/django/test/runner.py", line 1089, in run_tests old_config = self.setup_databases( ^^^^^^^^^^^^^^^^^^^^^ File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/django/test/runner.py", line 987, in setup_databases return _setup_databases( ^^^^^^^^^^^^^^^^^ File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/django/test/utils.py", line 206, in setup_databases connection.creation.create_test_db( File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/django/db/backends/base/creation.py", line 78, in create_test_db call_command( File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/django/core/management/ __init__.py", line 194, in call_command return command.execute(*args, **defaults) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/django/core/management/base.py", line 459, in execute output = self.handle(*args, **options) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/django/core/management/base.py", line 107, in wrapper res = handle_func(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/django/core/management/commands/migrate.py", line 323, in handle self.sync_apps(connection, executor.loader.unmigrated_apps) File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/django/core/management/commands/migrate.py", line 485, in sync_apps editor.create_model(model) File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/django/db/backends/base/schema.py", line 505, in create_model self.execute(sql, params or None) File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/django/db/backends/base/schema.py", line 202, in execute cursor.execute(sql, params) File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/django/db/backends/utils.py", line 79, in execute return self._execute_with_wrappers( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/django/db/backends/utils.py", line 92, in _execute_with_wrappers return executor(sql, params, many, context) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/django/db/backends/utils.py", line 100, in _execute with self.db.wrap_database_errors: File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/django/db/utils.py", line 91, in __exit__ raise dj_exc_value.with_traceback(traceback) from exc_value File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/django/db/backends/utils.py", line 103, in _execute return self.cursor.execute(sql) ^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/django/db/backends/mysql/base.py", line 76, in execute return self.cursor.execute(query, args) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/tests/.env/lib/python3.12/site-packages/MySQLdb/cursors.py", line 179, in execute res = self._query(mogrified_query) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/tests/.env/lib/python3.12/site-packages/MySQLdb/cursors.py", line 330, in _query db.query(q) File "/home/jenkins/workspace/django-mariadb/database/mysql/label/mariadb/python/python3.12/tests/.env/lib/python3.12/site-packages/MySQLdb/connections.py", line 265, in query _mysql.connection.query(self, query) django.db.utils.OperationalError: (1918, "Encountered illegal value 'μg/mL' when converting to latin1") ``` ---
**Author:** ![benc](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/benc/32/16767_2.png) [@benc](https://forum.djangoproject.com/u/benc)\ **Post date:** [November 27, 2024, 6:17pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/18 "2024-11-27T18:17:03Z")
@nessita Sure, I should be able to look at it some this afternoon. Are you seeing that error intermittently across various PRs, or is this the first time? ---
**Author:** ![nessita](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/nessita/32/12194_2.png) [@nessita](https://forum.djangoproject.com/u/nessita)\ **Post date:** [November 27, 2024, 6:27pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/19 "2024-11-27T18:27:51Z")
Thanks @benc. This is failing consistently since November 16th: ![image](https://us1.discourse-cdn.com/flex026/uploads/djangoproject/original/3X/2/7/2713c5829705446f2bb3ebac852e2580604ad01d.png) ---
**Author:** ![benc](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/benc/32/16767_2.png) [@benc](https://forum.djangoproject.com/u/benc)\ **Post date:** [November 27, 2024, 6:43pm UTC](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916/20 "2024-11-27T18:43:26Z")
Hmm, I’m trying to look around on [djangoci.com](http://djangoci.com), but I’m getting “Bad Gateway” errors now. [Next page](https://forum.djangoproject.com/t/ticket-18392-and-mysql-utf8mb4/34916.md?page=2)