MariaDB Illegal mix of collations és más kellemes dolgok... [megoldva]

Nem az a kérdés, hogy belefut-e az ember, hanem az, hogy mikor, és persze hogy hogyan mászik ki belőle, mert az insert/update/delete a webes alkalmazás felől/felé működik szépen, a táblák utf8, a table status azt mondja, hogy utf8_general_ci a collation, viszont: 


update VALAMI_TABLA set VALAMI_OSZLOP = SAJAT_FV(VALAMI_OSZLOP, 456567);
ERROR 1267 (HY000): Illegal mix of collations (utf8_general_ci,COERCIBLE)
 and (latin1_swedish_ci,IMPLICIT) for operation 'locate'

A Locate hívása valahogy így néz ki a függvényben: LOCATE(Valami, 'áéíóöőúüűÁÉÍÓÖŐÚÜŰ'), ahol a Valami VARCHAR(1).

Mondjuk ez alapján lehet, hogy nem kell csodálkozni: 


show variables like 'char%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | latin1                     |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | latin1                     |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.013 sec)

show variables like 'collation%';
+----------------------+-------------------+
| Variable_name        | Value             |
+----------------------+-------------------+
| collation_connection | utf8_general_ci   |
| collation_database   | latin1_swedish_ci |
| collation_server     | latin1_swedish_ci |
+----------------------+-------------------+
3 rows in set (0.001 sec)

Viszont kikalapálni ki kell, persze megyek rtfm ezerrel, de azért ha valakinek van javaslata, az ne tartsa magában.

Folytatásban már utf8 mindenki és minden (status szerint is), a függvény már nem collate hibával dől ki, hanem:

ERROR 1366 (22007): Incorrect string value: '\xC5' for column 'encodedInput' at row 1

Az egy varchar(4096) változó... Innentől kezdve passzolom a kérdést, "természetesen" nem tudom tesztelni az adatokat, hogy a átkonfigurálás után jól néznek-e ki az alkalmazásban, úgyhogy holnap folyt. köv.

2019.01.12 - megnézve a fejlesztő kolléga által "elkövetett" függvényt, kiderült a probléma oka: úgy gondolta, hogy ha valami varchar(1), azt számmá simán át lehet forgatni az ASCII() függvénnyel, és utána ezzel az értékkel matekozva, majd a kapott értéket CHAR() visszaalakítva hozzá lehet pattintani az utf8-as encodedInput végéhez. Hát pont nem :-)

Jó kis agytorna volt átrágni magam a kódján, és kitalálni, hogy mit _akart_ csinálni, majd átírni az egészet úgy, hogy tényleg azt csinálja, amit kell :-)

Most már csak az a kérdés, hogy ha a táblák utf8, de az adatbázis, a szerver latin1, akkor lesz-e a "default-character-set=utf8" beállításból és az alter database character set = 'utf8' collate = 'utf8_general_ci ' parancsból bárkinek is problémája...?

Úgy tűnik, nem lesz/lett... :-)

( szeim v | 2019. 01. 08., k – 18:24 )

Mysql alatt az utf8 az nem az. :)
Utf8mb4 környékén keresgélnék.

Ez gyk. azt jelenti, hogy pl. az emoji-k a mysql féle utf8-ba nem menthetők (5.7) utf8mb4 kell neki.

Ha esetleg jdbc-t használsz, az trükkös, mert a connection stringben utf8 kell hogy legyen, de a db encodingja utf8mb4.

Jó debugolást.

Ezt olvastam... Az emojikat letojom, nem érdekelnek, Árvíztűrő tükörfúrógép menje be/ki rendesen, és egy redva függvény legyen képes bizonyos oszlopok tartalmát adott eljárás szerint "elkódolni", akkor is, ha ékezetes szöveg van benne.
Ha ez elkódolós függvényt átírom úgy, hogy a visszaadandó varchar()-ba nem kerülhet ékezetes betű, akkor jó...

-Base64-ben nincs ekezetes betu.
-Set names utf8 megvolt? (gondolom igen)
-Egy szal 0xC5 szerintem sem valid UTF-8 ertek. Utana meg kell egy byte, aminek a felso bitje 1.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Nem base64, hanem egyedi, "olvasható" szöveggé kell egyirányú módon átalakítani, a kapott stringnek ráadául néhány speciális paraméternek is meg kell felelnie (ékezetest ékezetesre, nagybetűt nagybetűre, kisbetűt kisbetűre, számot számra, stb.), tehát pl. a "Háromszög"-ból legyen "Nőveueqáz" - a "miért"-et ne tölem kérdezd... (Gyakorlatilag végigmegy a függvény az inputon, és több paraméter alapján "cserélgeti" a karaktereket, és rakja össze a a kimeneti értéket, és amikor a végére ér, akkor visszaadja, amit kapott.
Ha az ékezetest-ékezetesre szabályt kiveszem, akkro jól működik, úgyhogy valahol ott lehet az eb elhantolva (a régi DB-hez hasonlóan "Mminden" utf8-ra beállított állapotban, ahol collation probléma már nincs), hogy a függvényben a varchar változóhoz az ékezetes betű "hozzápakolása" valami miatt nem jó.

Megszokás... Anno a Mysql a hiányosságai ellenére is (vagy épp azért) jobb teljesítményt nyújtott adott hardveren, faék egyszerű (volt), úgyhogy kétféle ember kezdte használni: boldog, boldogtalan.
Azóta fordult párat a világ, viszont a felhasználói bázis, a rá épülő alkalmazások hada (jó, nagyrészüket lehet más DB-re is tenni, csak általában a MySQL/MariaDB az elsődlegesen támogatott) viszo előre ezt a csodát...