hi paladox.
This need more documentation, but it's actually already possible :
Option "sessionVariables" permit to set session variable during connection:
for example :
"jdbc:mariadb://localhost/db?user=xx&password=yy&sessionVariables=character_set_client=utf8mb4,character_set_results=utf8mb4,character_set_connection=utf8mb4,collation_connection=utf8_spanish_ci"
this will do the equivalent of SET NAME utf8mb4 for the connection.
paladox why asking for "characterEncoding" support, if the only thing you'd want is utf8mb4, and special language rules?
maybe you only could ask for collation support, and then it would be up to the JDBC driver to check if your collation contains mb4 or not, and use castrated UTF8, or the full one.
diegos example is correct, but a little wordy, I think one could derive mb4 from collation name
And this useUnicode in MySQL driver is a not an example of how it must be done, right ?
Hi there,
sorry for raising the dead but I found this issue while browsing SO. With emojis becoming so prevalent people actually want to store their smiley faces and whatnot in their apps, which means in their databases. For MySQL server (not sure about MariaDB) this needs utf8mb4 in the server and in the client.
Is it possible to either document this better or add a property to the jdbc connection url?
Actual implementation depend on server default collation (@@character_set_server) :
if default collation is utf8_* (like "utf8_general_ci") server will use 3 bytes utf8 collation.
if not, connector use utf8mb4 (4 bytes utf8)
Implementation is misleading.
(In reality, java connector always send "real" utf8 to server, but server will truncate 4 bytes encoding characters)
Always setting utf8mb4 for communication between client and server would really simplify this.
Since 2.2.4, Connection encoding always uses utf8mb4, but for PRE 5.1 version that doesn't know utf8mb4. I think this solves any ambiguity on that.
Having different collation implementation can still make sense, but only to avoid any conversion for database encoded in other collation than utf8, but who would do that intentionnally now?