Adminer 3.6.4
Školení, která pořádám 
Adminer 3.6.4 přináší několik drobných vylepšení a oprav:
- Asi největší změna (i když spočívá jen ve změně stylu) je zafixování umístění stránkování. Řada uživatelů mě žádala, ať stránkování dám i nad výpis tabulky. Problém ale je, že zjištění celkového počtu řádků může trvat dlouho a je nesmysl na něj čekat před zobrazením dat. Dalo by se to vyřešit JavaScriptem, i když poněkud krkolomně. Fixní umístění stránkování považuji za lepší řešení – je vždy na jednom místě, nepotřebuje JavaScript a navíc je vidět i v případě posunutí stránky doprava. Tehdy se mi hodí především odkaz pro nahrání dalších dat AJAXem.
- S předchozí změnou souvisí i zvýšení výchozího počtu zobrazených záznamů ze 30 na 50. Při fixním umístění stránkování vypadá trochu hloupě, když je stránkování dole v okně osamoceno. Na poslední stránce to vypadá pořád trochu divně, ale než se na ni uživatelé dostanou, tak si na umístění snad zvyknou.
- Laboroval jsem i se změnou výchozího řazení záznamů (sestupně podle
auto_incrementsloupce), to jsem ale nakonec neudělal, protože zrušení tohoto výchozího řazení by bylo poněkud krkolomné. - Odkaz pro úpravu SQL dotazu na stránce výpisu jsem původně změnil na inline formulář, pak jsem změnu ale vrátil, protože někdy je na úpravu potřeba víc místa a navíc je trochu matoucí, že po úpravě dotazu se dostanu na stránku s obecným SQL dotazem. Inline formulář jsem nakonec zachoval alespoň po Ctrl+kliknutí na dotaz.
- Historie SQL příkazů se nyní zobrazuje od nejnovějších.
- Pokud při změně pohledu, triggeru nebo procedury došlo k chybě, tak se starý objekt smazal. Data pro nový objekt zůstala vyplněná ve formuláři, takže po opravě chyby se objekt v pořádku vytvořil, ale pokud po chybě uživatel formulář zavřel, tak přišel jak o starý, tak o nový objekt. Adminer se nyní v případě chyby pokusí vytvořit starý objekt.
- Pokud při vytváření nebo změně databázového uživatele zadáte nehašované heslo, tak se nově zahašuje v odděleném dotazu, který se neukládá do historie.
- U sloupců typu
timestampse nyní zobrazuje výběr pro možnostON UPDATE CURRENT_TIMESTAMP, který dříve byl v políčku pro výchozí hodnotu, což bylo matoucí. - Při používání vývojové verze jsem byl mnohokrát vděčný za změnu, která otevře databázi do nového okna, pokud na ni uživatel Ctrl+klikne. Adminer tohle dělá se všemi tlačítky, ale formulář pro výběr databáze tlačítko nemá, takže bylo potřeba trochu krkolomného JavaScriptu.
- Formulářová políčka od nedávna mají typ vstupu uzpůsoben pro mobilní prohlížeče. Nová verze toho využívá tak, že při smazání hledaného textu se smaže i sloupec, ve kterém se hledalo. Funguje to i v Chrome, Firefox tuto akci bohužel nenabízí.
- U ručně položených SQL dotazů se nově zobrazuje výsledek
EXPLAINvčetně informací o oddílech. - Při nahrání další stránky dat došlo k vymazání hodnot v inline editaci. Bylo to proto, že se pro připojení další stránky používala vlastnost
innerHTML. Nově se proto používá čistý DOM. - Po smazání záznamu Adminer přešel na první stránku výsledků. Bylo to proto, aby po smazání všech záznamů na poslední stránce nedošlo k zobrazení prázdné stránky. Ve většině případů se ale spíš hodí zůstat na stejné stránce, proto jsem toto chování změnil.
- Při exportu jediné tabulky se nově použije její název pro název souboru, při exportu více tabulek se použije název databáze. Dřív byl název souboru odvozen od toho, ze které stránky uživatel na export přišel, což nemuselo vždy odpovídat tomu, co skutečně exportoval.
- Adminer už dlouho bere na vědomí existenci rozšíření Suhosin a upozorní uživatele, pokud odešle formulář, který toto rozšíření ořízlo. Nově se děje totéž i pro konfigurační direktivu PHP
max_input_varsa děje se tak u všech formulářů. - Po odhlášení se nezrušil záznam o trvalém přihlášení, šlo o chybu z verze 3.6.0.
- Drobná změna užitečná pro mobilní prohlížeče spočívá v nepoužívání velkých písmen na začátku identifikátorů, protože běžná konvence je začínat identifikátory malými písmeny.
- Adminer nyní podporuje nové vlastnosti MySQL 5.6, konkrétně změny u časových typů a fulltextové indexy v InnoDB.
- Alter export jsem přesunul do rozšíření, protože už ho sám nepoužívám a mám za to, že ho nepoužívá ani moc dalších uživatelů.
- Při exportu se nastavovalo časové pásmo podle proměnné
time_zone. Není to ale tak jednoduché, protože časové pásmo nastavené na jednom serveru nemusí vůbec existovat na jiném serveru. Nejběžnější hodnota této proměnné je navícSYSTEMznamenající, že se má použít časové pásmo daného serveru. Nově se proto časové pásmo uvádí v hodinách, což je přenosné všude. - Ze záhlaví výpisu procesů nově vede odkaz do dokumentace.
- Export SQLite nyní obsahuje i indexy, které dříve chyběly.
Diskuse
Clary:
Bylo by možno v další verzi přidat ještě čas běhu dotazu pokud tento dotaz nevznikl ruční editací? Ve firmě používáme soubor s přírůstokvými sql dotazy, který se pouští na databázi před nasazením nové verze projektu a v tomto souboru do komentáře píšeme jak dlouho ten který dotaz běží. Takže si například v Admineru nakliknu přidání cizího klíče, dotaz v pohodě přidám do tohoto souboru, ale musím ho pak pouštět ještě jednou abych viděl jak dlouho běží.
Jakub Vrána 
:
Taky mě to často zajímá. Přidal jsem to do komentáře provedených dotazů a do další verze uvidím, jestli mě to tam nezačne štvát.
Jakub Vrána : Patrik Šíma:
1) nezvažuješ povolit issues na githubu?
2) nevím jak to mají ostatní, ale když chci řadit sloupec, tak v drtivě většině případu chci po prvním kliku sestupné řazení (DESC). teď to řadí vzestupně.
Jakub Vrána :
1. Ne, už takhle jsou informace na moc různých místech. Uvidíme, jak se povede upgrade SourceForge. Pak buď bugy přestěhuji na GitHub nebo zůstanu na SourceForge.
2. Sestupné řazení nabízí šipka, která se objeví po najetí na sloupec. Měnit to nebudu.
Jakub Vrána : Visitor:
Souhlasím s Patrikem...Většinou řadím kvůli toho, protože chci zobrazit nejnovější záznam (největší ID, největší čas, ...). Jinak vyhledávám...
Tharos:
Ahoj Jakube,já osobně bych třeba taky více ocenil výchozí řazení sestupně. A tak mě napadlo – co zavést vedle adminer.css ještě třeba nějaký adminer.ini, který by se zpracoval, pokud by bylo přítomen, a šlo by v něm podobné věci nastavit?
V.
Jakub Vrána :
Já jsem výchozí sestupné řazení zkoušel (zmiňuji to v bodu 3), ale chovalo se to divně:
Když dám vypsat záznamy, má se ve formuláři pro výběr zobrazovat, že se řadí sestupně? Pokud ano, jak to snadno zrušit, ideálně jedním kliknutím? Co když třeba položím GROUP BY dotaz (výběr sloupce a k tomu agregační funkce), kde je tohle řazení vyloženě nežádoucí?
Jakub Vrána : Milsa:
Konečne som sa začal učiť používať Alter Export a autor si ho vyhodí do rozšírenia. To ma trochu znechutilo.
Chcel by som poprosiť o natívnu podporu ZIPu. Často dostanem databázu v ZIPe a ak dávam niekde Adminer, nemám záujem hľadať aj rozšírenia, aby bol plne funkčný. Ak použijem rozšírenie, tak jednosúborovosť Admineru stráca význam. Takže rozšírenia zásadne nepoužívam. Teraz ZIPy riešim cez phpMyAdmin.
No a zaujímalo by ma aký význam má trvalé prihlásenie, keď nikde nefunguje? Na serveri, kde ho chcem používať mi po zavretí karty s otvorenou databázou a cca po pol hodine pri pokuse o opätovné prihlásenie Adminer po odkliknutí prihlasovacieho linku tento prihlasovací link zabudne a musím ho zadať ručne znova vrátane hesla. Predpokladám, že s tým súvisí pravidelné mazanie tempu po štandardnej inštalácii Debianu. Nedalo by sa to trvalé prihlásenie spraviť, aby bolo ozaj trvalé? Pri prihlasovaní na XAMPP server na localhoste mám ten istý problém. Adminer po nejakom krátkom čase (tuším na druhý deň) zabudne, že som zadal ako používateľa root.
Tiež by ma zaujímalo aký je rozdiel, keď zaškrtnem trvalé prihlásenie alebo nezaškrtnem, pretože Adminer sa vždy správa rovnako. Trvalé prihlásenie mám zaškrtnuté.
P.S.: Aký má význam vynucovanie zadania http:// v tomto formulári do políčka URL?
Michal:
Napadlo mě, co udělat nějakou stránku, obdobnou jQuery, kde by se zvolily pluginy a pak stáhl Adminer ? Jakub Vrána :
Taky mě to napadlo, ale spíš udělám autodiscovery pluginů. Všechny soubory Adminer*Plugin.php se prostě nahrají a použijí ve výchozí konfiguraci.
Jakub Vrána : Jakub Vrána:
Adminer nabízí plugin pouze pro export do ZIPu, import ze ZIPu nenabízí. Neimplementoval jsem ho hlavně proto, že není zcela intuitivní, jak by se měl chovat v některých okrajových případech:
1. V jakém pořadí se soubory mají zpracovat? Mají na to nějaký vliv podadresáře?
2. Které všechny soubory zpracovávat? Pouze *.sql nebo třeba i *.dump nebo všechny?
3. Co dělat se soubory, které se nezpracují?
Při zodpovězení těchto otázek bych podporu pro ZIP asi i dodělal, i když je mnohem krkolomnější než GZ.
Trvalé přihlášení ukládá informace do cookie. Z důvodu bezpečnosti se ukládají šifrovaně. Klíč pro rozšifrování je uložen na serveru, poskytuje ho metoda permanentLogin(). Její výchozí implementace tento klíč ukládá do dočasného adresáře na serveru. Pokud je tento adresář periodicky promazáván, tak dočasné přihlášení skutečně funguje jen chvíli. Nejlepší řešení v tomto případě je vytvořit triviální rozšíření, které v této metodě bude vracet nějaký pevný řetězec. Nejsnáze podle vzoru na http://www.adminer.org/en/extension/ (stránka při každém nahrání generuje náhodný klíč).
Políčko URL v tomto formuláři je standardní <input type="url">.
Jakub Vrána: Milsa:
Úplne by stačilo, keby to vedelo spracovať jeden zoZIPovaný súbor. V oblasti exportu/importu MySQL som sa s inou možnosťou ani nestretol. Myslím, že väčšina bude so mnou súhlasiť.
Milsa:
Rozšírenia nie, potom skončím ako s Firefoxom, pokiaľ ho nenakŕmim aspoň 6+ rozšíreniami, tak s ním nedokážem v kľude robiť.
Jirka:
Ahoj Jakube,
nebudu obtěžovat technickými dotazy, především jsem Tě chtěl veřejně před všemi pochválit a poděkovat, že Adminera děláš a s jakou profesionalitou. S jeho pomocí udržujeme snadno databázi závodníků pro čipovou časomíru, když dohledávám data a časy, tak jedině s jeho pomocí.
Díky!!!
Milsa:
Musím len súhlasiť, hoci moje komentáre vyznievajú dosť kriticky, Adminera si neviem vynachváliť.
Coudy:
Cau Jakube,muzes mi rict kde se v 3.6.4 zobrazuje ten EXPLAIN ? Nemuzu ho nikde najit...
Jakub Vrána :
Zobrazuje se po ručním provedení SQL dotazu SELECT.
Jakub Vrána : Coudy:
Muzes mi nejak lepe popsat co je mysleno "ručním provedení SQL dotazu SELECT" ?Pokud se prihlasim do Adminera, kliknu na "SQL command", zadam neco ve smyslu "SELECT * FROM tb_users" a kliknu na "Execute" tak stale nikde zadny EXPLAIN nevidim :-(
Jakub Vrána :
Je to pod tabulkou s výsledky. Vypadá to nějak takhle:
SELECT 1
+---+
| 1 |
+---+
| 1 |
+---+
1 row (0.002 s) Edit, EXPLAIN, Export
Jakub Vrána : Coudy:
Tak jak to popisujes mi to funguje ve verzi 3.6.3, ale v nejnovejsi 3.6.4 uz ne.Radeji prikladam na ukazku screenshoty..
Verze 3.6.3 s EXPLAIN:
http://s7.postimg.org/huggir8u3/363.png
Verze 3.6.4. bez EXPLAIN:
http://s7.postimg.org/swljh72wr/364.png
Jakub Vrána :
Díky za upozornění, projevovalo se to v MySQL < 5.1. Opravil jsem to v Gitu.
Jakub Vrána : Diskuse je zrušena z důvodu spamu.
© 2005-2024 
