Adminer 3.3.0
Školení, která pořádám 
Nová verze Admineru nemá žádnou zásadní novinku, spíše spoustu menších drobností. Největší novinkou mělo být začlenění editoru se zvýrazňováním zdrojového kódu CodeMirror, s chováním jsem ale nebyl zcela spokojen, takže i když už byl ve vývojové verzi funkční, zase jsem ho odstranil. A to fungovalo už i doplňování názvů tabulek pomocí Ctrl+Space.
Další novinky tak zásadní nejsou:
- Inline editace se dá zrušit pomocí klávesy
Esc. - Adminer obsahuje komplexní rozhraní pro nastavení práv. V nové verzi jsem přidal zkratku pro nastavení práv aktuální databáze.
- U indexů lze nyní určit jejich název. S přidáním této možnosti jsem dlouho váhal, protože ve většině případů název indexu definovat potřeba není, takže by políčko pro zadání názvu uživatele zbytečně rozptylovalo a i když by bylo nepovinné, tak by se zdržovali jeho vyplňováním. Nakonec jsem to vyřešil tak, že se název indexu JavaScriptem průběžně sestavuje z názvů sloupců, kterými je tvořen. To zároveň vytváří lepší názvy indexů než výchozí způsob v MySQL (kde je název indexu odvozen jen z prvního sloupce), což oceníme např. v příkazu
EXPLAIN. - Při vytvoření indexu vybráním sloupce se vytvoří místo na nový index (chyba #3282127).
- Při hromadné editaci lze zachovat hodnotu sloupce
timestamp(chyba #3312614). - Datovému typu
bitlze nastavit výchozí hodnotu. - U cizího klíče se zobrazuje jeho název (v bublině).
- V přehledu tabulky se zobrazuje výchozí hodnota sloupců.
- U řetězcových datových typů se zobrazuje způsob jejich porovnání (v bublině).
- Klávesová zkratka
Alt+Shift+1(kombinace kláves může být závislá na prohlížeči a operačním systému) vede na domácí stránku,Ctrl+Shift+Enterv editaci na Uložit a pokračovat. - Při spuštění SQL příkazu z webového serveru (pomocí souboru
adminer.sqlnahraného např. pomocí FTP) se ve výchozím nastavení nezobrazují prováděné příkazy. - Při exportu a importu z výpisu dat se do cookie ukládá vybraný formát dat.
- Pod dotazy
SELECTv ručně spuštěném SQL příkazu se zobrazuje jejichEXPLAIN. Z něj nyní vedou odkazy na dokumentaci jednotlivých sloupců. Tato změna si vyžádala i úpravu dokumentace MySQL. Odkazy nově vedou i na tabulky a indexy. - Některé chybné MySQL příkazy (např.
EXPLAIN SELECT x) nezobrazily chybu. - V PostgreSQL se zobrazují cizí klíče z jiných schémat. Bohužel je zatím nelze editovat.
- Podpora stránkování pro Oracle – na možnost použití této funkce návrháři zjevně nemysleli.
- V Editoru se při editaci cizích klíčů odjakživa zobrazují hodnoty z odkazovaných tabulek pomocí políčka
<select>. Je to ale omezeno jen na tabulky do 1000 záznamů, protože delší výběry by mohly editaci neúnosně zpomalit. Nově se pro tyto dlouhé výběry používá AJAXový našeptávač. - V Editoru se také nově zobrazuje název odkazovaného záznamu v PostgreSQL. Jeho výchozí detekce totiž byla pomocí datového typu
varchar, ale PostgreSQL používácharacter varying. - V Editoru se při nepovinném odkazu na řetězcový cizí klíč preferuje místo prázdného řetězce
NULL(chyba #3323800) - V ukázce použití Editoru se při výpisu zobrazuje jen prvních pět sloupců s komentářem. Změnil jsem chování tak, aby se k tomu zobrazily ještě prohledávané sloupce.
- Pomocí přizpůsobení se dá vyměnit favicon (metoda
head). - Metoda
namenově může vracet i odkaz – používám pro odkaz z administrace do prezentace. - Výchozí bezpečnostní hlavičky se nyní dají poslat prostým vrácením hodnoty true z metody
headers. - Přibyl litevský a rumunský překlad.
Diskuse
Ján Jaďuď:
Obrovsky palec nahoru za default hodnoty pri prehlade tabulky, to bola snad jedina vec, ktora mi poriadne v Adminerovi chybala!
pidiďundina:
pro NULL to ukazuje na první pohled jakousi kostičku, ze které po bližším zkoumání udělá [ ]. možná by to se hodilo napsat tam 'NULL'.
Jakub Vrána 
:
NULL by se vůbec nemělo zobrazovat. A [] pro výchozí hodnotu prázdný řetězec je podle mě v pořádku. Pošli prosím příklad (CREATE TABLE a výstup toho, co ukazuje Adminer).
Jakub Vrána : pidiďundina:
Zdravím. "Kostička" vznikne u sloupce s DEFAULT '' v příkazu ALTER TABLE + výchozího fontu (Verdana) s velikostí o stupínek menší než defaultní CSS skin (možná to bude vidět po odzoomování Ctrl-minus). Jakub Vrána :
Zobrazit prázdný řetězec pro prázdný řetězec mi přijde zcela v pořádku. Zobrazit NULL by bylo vážnou chybou.
Jakub Vrána : fos4:
+1 za ulozit a pokracovatMichal:
CodeMirror byl tedy nastálo odstraněn nebo jej plánuješ doladit a v nějaké verzi opět nasadit ? Jakub Vrána :
Možná se k němu časem vrátím, možná použiji jiného. Funkčnost napovídání názvů tabulek a sloupců v SQL příkazu mi chybí, tímhle by se dala elegantně získat.
Jakub Vrána : 
Opravdový odborník :-):
Tahle knihovna se používá v phpMyAdminovi - možná by se šlo inspirovat tam.
Opravdový odborník :-): Jakub Vrána :
Žádné použití nevidím.
Jakub Vrána : Opravdový odborník :-):
Koukněte na demo: http://demo.phpmyadmin.net/master/ používá se tam pro zvýrazňování syntaxe během psaní SQL dotazů.
Opravdový odborník :-): Jakub Vrána :
Do značné míry to trpí těmi stejnými problémy, kvůli kterým jsem to vyhodil z Admineru. Zkuste si třeba zadat řetězec širší než obrazovka – chování je značně podivné, důsledkem je třeba to, že při běžném psaní přestane být vidět kurzor. Např. Ctrl+šipky se chovají taky mírně odlišně než normálně. Při Ctrl+Z po smazání textu kurzor skočí jinam, než by měl. V Admineru mi špatně skákal kurzor i při Ctrl+Home a Ctrl+End (možná kvůli tomu, že jsem neměl zobrazená čísla řádek). Všechno to jsou malichernosti, mě ale v součtu natolik rozčilují, že jsem raději zůstal bez zvýrazňování syntaxe.
Jakub Vrána : Adam Bísek:
Měl bych takový malý feature request.Hodilo by se mi, kdyby šlo nějakým způsobem skrýt některé databáze (jako to umožňuje phpMyAdmin).
Typicky např. information_schema - kolega použivá myAdmin, já zas Adminer - a zbytečně se mi listu databází plete.
Rozšíření Admineru toto bohužel neumožňuje a zatím jsem to vyřešil zásahem do funkce get_databases(), což se mi ani trochu nelíbí.
Jakub Vrána :
Rozšíření to umožňuje pomocí metody navigation(). Nad zjednodušením se zamyslím.
Jakub Vrána : Radecek:
Mel bych napad o male zrychleni testovani dotazu a to umisteni dvou tlacitek odeslat, jedno dole a druhe na hore. Diky za odpoved.http://awesomescreenshot.com/0b8h0p4a7
Jakub Vrána :
Druhé tlačítko přidávat neplánuji.
Jakub Vrána : 
Filip Procházka:
Ahoj Jakube právě mě napadl feature request.
Potřeboval jsem odladit dotaz na nějakých cca 60k záznamů a exportovat. Ale problém je, že Adminer umře na memory limitu. Takže jsem dotaz ladil přes HTML inspektora prohlížeče a upravoval v hidden inputu SQLko a opakovaně exportoval.
Kdyby tě napadl nějaký pěkný způsob, jak vykonat dotaz a exportovat ho, bez nutnosti ho předně kompletně vypsat... :)
Filip Procházka: Jakub Vrána :
Odstranil bych spíš příčinu problému – paměť by dojít neměla. Adminer se v SQL příkazu snaží s pamětí zacházet velmi hospodárně, takže jestli se jí někde plýtvá, tak je to chyba a potřeboval bych její podrobnější popis.
V běžném výpisu tabulky se s pamětí tak šetrně nezachází, ale tam je zase stránkování a exportovat lze výsledek všech stránek.
Jakub Vrána : Filip Procházka:
Měl jsem za úkol vytvořit sestavu z několika tabulek, která měla spoustu sloupců i dopočítávaných a z různých tabulek. Takže joiny, groupy, ... Tisíce řádků... Takže žádné stránkování.
Úplně by stačilo, kdyby šlo exportovat dotaz, bez nutnosti ho nejprve zobrazit :) Stejně bych nerad měl v prohlížeči 10MB textu a dlouze scroloval dolů k tlačítku export.
Možná by šlo u exportu udělat nějaký přepínač, který by mi skryl tabulky a zobrazil pole na SQL :)
Nepotřebuji to tak často, ale když už, tak to musím takto ohýbat.
Filip Procházka: Jakub Vrána :
Jedna věc je 10 MB textu a nutnost scrolovat. To je nepohodlí, se kterým se dá žít.
Druhá věc je došlá paměť. To je chyba, kterou bych rád odstranil. Tebou dosud poskytnuté informace mi k tomu bohužel nijak nepomůžou.
Jakub Vrána : pidiďundina:
Nabízí se tedy naplnění ad hoc tabulky a její vyexportování jako celku…pidiďundina:
Pro výpis tabulky má samozřejmě Adminer limit na maximální počet řádků a nedopustí, aby se obrovské tabulky vypisovaly celé.Naopak, v sekci "SQL příkaz" Adminer vypíše bezhlavě každý SELECT bez ohledu na to, že příliš mnoho záznamů může až shodit prohlížeč.
(Dokážu si představit i opačný případ - kdy by automatické utnutí všech výpisů za limitem bylo kontraproduktivní - třeba pro toho, kdo by hledal hodnotu na 31. řádku a měl by jich jen prvních 30.) Nešlo by, nicméně, s tím něco dělat a přizpůsobit se obou případům?
Otázka extra pro Jakuba: Případ, kdy se Adminer pokusí vypsat milion záznamů z SQL okna a shodí při tom prohlížeč, je podle tebe (principielně, prakticky, celkově, s ohledem na priority Adminera…) chyba uživatele nebo chyba Adminera?
Jakub Vrána :
SQL příkaz je velmi nízkoúrovňový a jako takový by podle mě měl dělat přesně to, co zadá uživatel. Když zadá, že chce vypsat milión řádků, tak pro to nejspíš má nějaký důvod. Omezit počet řádků úpravou dotazu si může vždycky.
Jakub Vrána : juzna.cz:
Ten duvod bude nejcasteji asi nepozornost a druhy nejcastejsi uzivatelova blbost ;) u me to jsou dokonce jedine dva duvody, proc mi adminer obcas shodi cela Xka
pidiďundina:
Adminer může být podle jisté paralely robot, navržený sloužit svému pánovi. A SELECT s milionem řádků pak příkaz, aby se zničil. Platí pravidla robotiky i tady? ;-) Jakub Vrána :
Reklamujte si to u výrobce svého prohlížeče, primárně to je totiž jeho chyba. Adminer nic nelegálního nedělá, žádný limit velikosti HTML stránky pokud vím neexistuje. Nechápu, proč by prohlížeč kvůli velkému dokumentu měl padat (nebo s sebou dokonce brát Xka).
Na straně serveru se Adminer snaží chovat slušně – výsledek ze serveru načítá postupně, průběžně ho taky posílá do prohlížeče a použitou paměť se snaží minimalizovat. Pokud by se našla chyba v tomhle, tak jsem ochoten ji řešit, jak už jsem ostatně uvedl.
Jakub Vrána : pidiďundina:
Přemýšlela jsem nad tím a našla jsem argument proti - výstup, který Adminer posílá, by mohl být nejenom zobrazován v prohlížeči (byť je to v 99 % nejběžnější případ) ale též například posílán na standardní výstup, popř. z něj přesměrováván do souboru (jehož velikost už je omezena velikostí disku, ne paměti).pidiďundina:
A teď pár návrhů na onu přizpůsobitelnost. (Uvažuju nahlas...) Je jasné, že blok v SQL oknu může libovolně kombinovat příkazy, kde data upravuje (UPDATE, ALTER, …) nebo vypisuje (SELECT, SHOW). Může mít třeba 20 UPDATů a 30 SELECTů, některý z nich vypisující pár řádků a některý snažící se vypisat příliš mnoho řádků pro zobrazení v prohlížeči. Pokud by každý SELECT byl "oseknut" na počet zobrazených záznamů (nastavený z běžného výpisu tabulky), mohlo by to uživatele otravovat (a pokud by se nedalo snadno dostat k těm zbylým, pak by to sráželo použitelnost). Na druhé straně, pokud by vykonání bloku příkazů skončilo prvním SELECTem z obrovské tabulky (což je, pokud vím, současný stav) tak to také není nic moc. Ještě dodám - předpoklad je SELECT bez klauzule LIMIT (pokud si uživatel určí limit milion záznamů a dostane je a při tom mu to shodí prohlížeč, pak je to jeho blbost).Napadá mě:
1. výpis prvních X záznamů s odkazem na kompletní výpis (který se otevře v novém okně)
2. stránkovaný výpis:
2.1. do <iframe> - (což se mi nelíbí - takže jen pro úplnost)
2.2. do <div> se zobrazením dalších stránek přes AJAX
paranoiq:
pokud uživatel napíše SELECT bez klauzule LIMIT, pak je to proto, že chce všechny výsledkyJakube, nejjednodušší řešení by asi bylo, kdyby se u SQL pole rovnou zobrazovalo tlačítko pro export (bez zobrazení výsledku). pokud někdo chce ladit dotaz s milionem řádků, musí beztak použít pro prohlížení jiný nástroj než HTML prohlížeč
Jakub Vrána :
Problém je, že do SQL pole lze zadat více příkazů. Tlačítko pro export by to muselo zohledňovat.
Jakub Vrána : Filip Procházka:
To ale není takový problém ne? :)
<?php if(substr_count($sqlDotaz, ';')>1) { die('Exportovat je možné pouze jeden dotaz'); } // velice zjednodušená varianta ?>
Filip Procházka: pidiďundina:
„pokud uživatel napíše SELECT bez klauzule LIMIT, pak je to proto, že chce všechny výsledky“…a nebo předpokládá, že má co do činění s inteligentním nástrojem, který nedopustí spadnutí prohlížeče
…a nebo sehrála úlohu jeho nezkušenost
…a nebo sehrála úlohu jeho hloupost
…a nebo sehrála úlohu jeho nepozornost (bohatě stačí přistoupit k tabulce poprvé a nezjistit si její velikost)
dokonce by se dalo argumentovat i tak, že ono "[uživatel] chce všechny výsledky" znamená "mít k nim přístup" (a to třeba nebo mimo jiné přes odkazy na další stránky) – ne nutně být zahlcen milionem záznamů najednou (což já beru jako primitivní formu zprostředkování dat, ale to je jen můj soukromý názor).
simonik:
Zdravím,používám Adminer 3.3.3 a při větším importu pomoci adminer.sql (18MB) adminer zamrzne. Zobrazí se pouze začátek stránky bez chyby a do databáze se přenese jenom část tabulek. Co byste poradil?
Děkuji.
Jakub Vrána :
Zkusil bych zjistit, na kterém příkazu to zamrzne. Pokud v importu nejsou důvěrná data, tak mi ho můžete i poslat.
Jakub Vrána : Jakub Vrána :
Opravil jsem to v Gitu, ale řádně jsem se zapotil. Díky za data, bez nich bych na to asi nepřišel.
Jakub Vrána : simonik:
Rádo se stalo. A kdy bude k dispozici opravená verze? Jakub Vrána :
Novou verzi plánuji vydat v druhé polovině září. Stáhnout z Gitu to jde ale hned. http://www.adminer.org/#download
Jakub Vrána : Tharos:
Ahoj Jakube,poměrně často by se mi hodila jedna věc (ale upřímně nevím, kolika dalším lidem ještě - možná jsem exot), a to možnost CSV importu přímým textovým vstupem.
Díky za zvážní :).
Jakub Vrána :
Přímo v Admineru mi to příliš velký smysl nedává. Ale plugin by se na to udělat dal. Pokud ho vytvoříš, tak ho rád zveřejním.
http://www.adminer.org/cs/plugins/
Jakub Vrána : duppo:
Zdravím,adminer je super nástroj, velmi rychle jsem si na něj zvykl a pracuji s ním velmi efektivně. Moc za něj děkuji.
Mám však problém: velmi často potřebuji vypisovat jeden dotaz, který vrací tisíce záznamů a propojuji v něm pár tabulek. Tento dotaz se vypíše buď komplet na jednu stránku (obrovská tabulka) a nebo mu dám LIMIT a v tom případě vidím jen něco. Nešlo by do těchto dotazů přidat podporu stránkování? Bylo by to moc fajn.
Také mě ještě napadla drobná vychytávka, a sice jestli by byla možná editace dvojklikem i v dotazech s více tabulkami (pochopitelně pouze za situace, že je jednoznačné, z jaké tabulky ten sloupec tahá)? Také by to bylo fajn, už jsem se párkrát přistihl, že zkouším dvojklik někde, kde nefunguje.
Jinak ještě jednou chválím perfektně odvedenou práci, neznám nic, v čem by se mi pracovalo tak dobře a rychle.
duppo
Jakub Vrána :
Snahou SQL příkazu je dělat přesně to, co se mu zadá. Takže podporu stránkování se mu přidat nechystám. Vedle limitu do dotazu můžeš dát i ofset.
Přidat podporu přímé editace do SQL příkazu by šlo, ale dělat se mi to nechce.
Jakub Vrána : 
Martin :
Ahoj Jakube. Moc se omlouvám, že tě otravuji, ale dělám na tom už půl dne a prostě jsem na to nepřišel.
Hledám, jak vybíráš všechny sloupce ikdyž je v příkazu JOIN. Nepřišel jsem na to. Tak jsem hledal, a zjistil že se volá funkce fetch_field(). V celém admineru jich je 8. Ke každému jsem dal die() hned po { ale ani v jednom "neumře". Mám MySQLi extenzi ale tu pravou funkci jsem prostě nenašel. Mohl by si mi říct, kde je funkce (v 3.3.3) fetch_field() pro MySQLi ?
Martin : Jakub Vrána :
Tady: http://php.net/mysqli-result.fetch-field. Ovladač pro MySQLi vrací přímo objekty vestavěné třídy.
Jakub Vrána : Diskuse je zrušena z důvodu spamu.
© 2005-2024 