Adminer 4.8.0

Školení, která pořádám

Krátce po vydání předchozí verze jsem zjistil, že jsem opětovným zapnutím PHP varování rozbil vytvoření tabulky v PHP 8. Adminer 4.8.0 především opravuje tuto chybu, ale kromě toho jsem udělal i řadu dalších změn:

Rozhodl jsem se ovladače pro SimpleDB, Firebird a ClickHouse přesunout do pluginu. Myslím, že je málokdo používá a jejich uživatelům snad nebude vadit, že si musí stáhnout ještě plugin. Důvody jsou dva: zmenšení attack surface Admineru a zmenšení velikosti výchozí distribuce. Sám používám verzi Admineru pouze pro MySQL, takže pro mé osobní použití žádná změna nenastane, ale především uživatelé ostatních databází používají kompletní Adminer. Verze např. pouze pro PostgreSQL se sice dá snadno zkompilovat, ale já ke stažení tyto verze nenabízím, takže by si je uživatelé museli vytvořit sami. O této změně jsem přemýšlel několik let a představoval jsem si, že bude docela komplikovaná, nakonec to ale byly dva poměrně jednoduché commity.
V editaci se dá použít pseudo-funkce SQL, která data do databáze pošle neošetřená. Používám ji např. v kombinaci s funkcí SUBSTR při změně záznamů. Teď jsem tuto funkci přidal i do formuláře pro vložení záznamu a používám ji pro políčka s výchozí hodnotou vypadající jako funkce. (bug #713)
SQL Export obsahuje komentář s verzí Admineru a databázový systém. Nyní jsem přidal i verzi databáze. Jedním z důvodů je, že uživatelé mi někdy pošlou export databáze pro zreprodukování chyby, ale verzi neřeknou.
MySQL 8 zpřísnilo porovnávání datumů, takže date = 'a' nově skončí chybou. Adminer na to reaguje tak, že při vyhledávání ve všech sloupcích datumové sloupce přeskakuje, pokud hledaná hodnota nevypadá jako datum. Odjakživa něco podobného dělá i s číselnými sloupci.
MySQL 5.6 přidalo příkazu EXPLAIN klauzuli PARTITION, kterou Adminer používal. MySQL 8 ale tuto klauzuli zase odstranila, takže ji Adminer v této verzi už nepoužívá.
Adminer 4.7.9 v PostgreSQL 11 začal vytvářet primární klíč pro auto increment sloupce. Nová verze to dělá ve všech verzích.
Export z PostgreSQL někdy neobsahoval poslední použitou hodnotu ze sekvencí, což skončilo syntaktickou chybou. Nová verze v takovém případě klauzuli s poslední hodnotou vůbec nevypisuje. (bug #768)
V PostgreSQL se mohl zobrazit stejnojmenný trigger z jiného schématu. (PR #412)
V PostgreSQL jsem opravil zpracování funkcí s více parametry ve výchozí hodnotě. (bug #736)
V PostgreSQL se u bytea sloupců místo hodnoty NULL zobrazoval prázdný řetězec.
S ovladačem PDO_PgSQL se hodnoty false v editačním formuláři zobrazily jako NULL.
Po zhruba dvou letech jsem se odhodlal mergnout změny v Oracle od jednoho uživatele, které ani nemám jak otestovat. Ten je naštěstí otestoval, takže by v Oracle nově měla fungovat změna indexů, počítání tabulek v databázi, import z CSV a velikost řetězcových typů.
Odhodlal jsem se vyzkoušet MongoDB, které jsem doteď nechal v rukou uživatelů a byl jsem celkem zděšen. Chyby se zobrazovaly jako neošetřené výjimky. Označení řádku a pokus o jeho smazání skončil smazáním všech řádků. Nejhorší problémy jsem snad opravil, ale bez zásahu někoho, kdo MongoDB opravdu rozumí a nebojí se dělat změny, to asi moc dobře fungovat nebude.

Jakub Vrána, Adminer, 10.2.2021, diskuse: 4 (nové: 0)

Diskuse

smrdící epidemie:

Díky za každou novou verzi.

19.2.2021 22:02:39

Magdalena Bobramyla Rettigová:

Ahoj, Jakube.
Hlásím chybku. Na stránce "SQL příkaz" hodí tuto PHPčkovskou chybu:

Warning: Uninitialized string offset 0 in <cesta>\adminer.php on line 1583

při spuštění špatně ošetřeného příkazu (např. INSERT INTO tabulka SET nazev='McDonald's' ON DUPLICATE KEY UPDATE nazev='McDonald's';), resp. - v mém případě komplikovanějšího insertu, kdy neošetřený string byl v příkazu 5x a za ním následovaly další inserty.

Podaří se ti tu chybu simulovat u tebe?

9.3.2021 16:03:16