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:

Jakub Vrána, Adminer, 20.7.2011, diskuse: 44 (nové: 0)

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'.

ikona Jakub Vrána OpenID:

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).

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).

ikona Jakub Vrána OpenID:

Zobrazit prázdný řetězec pro prázdný řetězec mi přijde zcela v pořádku. Zobrazit NULL by bylo vážnou chybou.

fos4:

+1 za ulozit a pokracovat

Michal:

CodeMirror byl tedy nastálo odstraněn nebo jej plánuješ doladit a v nějaké verzi opět nasadit ?

ikona Jakub Vrána OpenID:

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.

ikona Opravdový odborník :-):

Tahle knihovna se používá v phpMyAdminovi - možná by se šlo inspirovat tam.

ikona Jakub Vrána OpenID:

Žádné použití nevidím.

ikona 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ů.

ikona Jakub Vrána OpenID:

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.

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í.

ikona Jakub Vrána OpenID:

Rozšíření to umožňuje pomocí metody navigation(). Nad zjednodušením se zamyslím.

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

ikona Jakub Vrána OpenID:

Druhé tlačítko přidávat neplánuji.

ikona 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... :)

ikona Jakub Vrána OpenID:

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.

ikona 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.

ikona Jakub Vrána OpenID:

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.

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?

ikona Jakub Vrána OpenID:

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.

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? ;-)

ikona Jakub Vrána OpenID:

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.

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ýsledky

Jakube, 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č

ikona Jakub Vrána OpenID:

Problém je, že do SQL pole lze zadat více příkazů. Tlačítko pro export by to muselo zohledňovat.

ikona 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 ?>

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.

ikona Jakub Vrána OpenID:

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.

simonik:

Zdravím,
zkusil jsem data  poslat e-mailem.
Š.

ikona Jakub Vrána OpenID:

Opravil jsem to v Gitu, ale řádně jsem se zapotil. Díky za data, bez nich bych na to asi nepřišel.

simonik:

Rádo se stalo. A kdy bude k dispozici opravená verze?

ikona Jakub Vrána OpenID:

Novou verzi plánuji vydat v druhé polovině září. Stáhnout z Gitu to jde ale hned. http://www.adminer.org/#download

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í :).

ikona Jakub Vrána OpenID:

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/

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

ikona Jakub Vrána OpenID:

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.

ikona Martin OpenID:

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 ?

ikona Jakub Vrána OpenID:

Tady: http://php.net/mysqli-result.fetch-field. Ovladač pro MySQLi vrací přímo objekty vestavěné třídy.

Vložit příspěvek

Používejte diakritiku. Vstup se chápe jako čistý text, ale URL budou převedeny na odkazy a PHP kód uzavřený do <?php ?> bude zvýrazněn. Pokud máte dotaz, který nesouvisí s článkem, zkuste raději diskusi o PHP, zde se odpovědi pravděpodobně nedočkáte.

Jméno: URL:

avatar © 2005-2014 Jakub Vrána. Publikované texty můžete přetiskovat pouze se svolením autora. Ukázky kódu smíte používat s uvedením autora a URL tohoto webu bez dalších omezení Creative Commons. Můžeme si tykat. Skripty předpokládají nastavení: magic_quotes_gpc=Off, magic_quotes_runtime=Off, error_reporting=E_ALL & ~E_NOTICE a očekávají předchozí zavolání mysql_set_charset. Skripty by měly být funkční v PHP >= 4.3 a PHP >= 5.0.