skeema / skeema / 8514369763

92%

push

github

workspace=docker: fix utf8mb4 default collation for 5.x arm64 edge case

Background:

When using workspace=docker on an arm64 system (such as Apple Silicon or AWS
Graviton) along with flavor=mysql:5.7 (or any 5.x), Skeema uses a mysql:8.0
image instead, because arm64 builds for 5.x are not available on DockerHub.

Previously, this situation was problematic when CREATE statements referenced
the utf8mb4 character set without an explicit collation clause, because the
default collation for this charset changed between MySQL 5.x and 8.x. Worse
still, the default in 8.x does not even exist in 5.x (except in Aurora 5.7,
where AWS backported it).

The result would be that the workspace would introspect affected objects as
using utf8mb4_0900_ai_ci, while the target database used utf8mb4_general_ci;
so DDL would be emitted which attempts to change columns from one to the
other. This DDL was invalid in mainline 5.x, or valid but unexpected in
Aurora 5.7. For original report, see this issue comment:
https://github.com/skeema/skeema/issues/226#issuecomment-1987751110

Solution in this commit:

When substituting 8.0 for 5.x on arm64, we now force Skeema's connections to
use SET SESSION default_collation_for_utf8mb4=utf8mb4_general_ci. This causes
the server to interpret utf8mb4 (when no explicit collation is specified) as
having the old 5.x default collation behavior, rather than 8.0's.

The server introduced this session variable only for its own logical
replication purposes (under similar motivations to our own), and warns users
against setting it. Indeed, this variable cannot be set in a server option
file, nor does it PERSIST properly. However, at the session level it works as
expected in 8.0, and we don't ever need to set it in 8.1+, so this solution
appears to be safe despite any server-side deprecation plans in a future
release series.

To be clear, this code path only affects workspace=docker, and only with
flavor=mysql:5.x while using an arm64 cpu. This us... (continued)

0 of 12 new or added lines in 1 file covered. (0.0%)

9731 of 10447 relevant lines covered (93.15%)

1.11 hits per line