Další vývoj phpMinAdmin
Školení, která pořádám
Pro druhou verzi nástroje pro správu MySQL databáze phpMinAdmin chystám především podporu více databázových serverů. Začal jsem s SQLite, které alespoň občas používám, výhledově plánuji začlenit i PostgreSQL a případně další databáze, ale jejich podporu nechci dělat sám, protože je téměř nepoužívám. Využil bych tedy výhod open source vývoje a nechal bych jejich podporu udělat někoho, kdo tyto databáze používá.
Není třeba se obávat, že by se z nástroje stal nabubřelý moloch. Stejně jako lze nyní vytvořit jednojazykovou verzi (která je téměř o třetinu menší než verze se všemi jazyky), tak půjde vytvořit i jednodatabázová verze. Pokud se tedy k různým databázím nepotřebujete připojovat, tak bude stačit stáhnout tuto verzi.
Druhá novinka, jejíž přidání zvažuji, je podpora dotazů do více tabulek. Jde o to, že by šlo ve výpisu tabulky určit, že se mají získat i sloupce z propojených tabulek. Spojení by probíhalo výhradně podle cizích klíčů definovaných u tabulek InnoDB, aby nebylo nutné pracně definovat podmínku spojení. Možná využití vidím dvě:
- Při pohledu na data tabulky se hodí vědět, co se skrývá za jednotlivými identifikátory. Např. místo ID uživatele je vhodné vidět jeho jméno.
- Nástroj se dá použít k poměrně jednoduchému sestavení i poměrně složitých dotazů z více tabulek. Takto sestavený dotaz se pak dá použít např. v PHP skriptu.
Prototyp této funkce už mám připravený (je vidět na obrázku), ale jeho začleněním si ještě nejsem zcela jist.
Třetí novinkou, jejíž přidání zvažuji, je kontrola cizích klíčů při editaci dat. Představoval bych si to tak, že jakmile člověk začne vyplňovat hodnotu do pole s cizím klíčem, tak se zobrazí našeptávač s výpisem odkazované tabulky. V tomto výpisu by šlo vyhledávat i podle jiných sloupců, takže by bylo možné snadno dohledat ID odpovídajícího záznamu.
Co si o těchto funkcích myslíte? Využili byste je nebo phpMinAdmin jenom zbytečně zvětší? Případně jaké další funkce byste chtěli? Nebo by měl být nástroj naopak ještě jednodušší?
Diskuse
Rudolf Náprstek:
Bylo by mě hodně líto, kdyby tak prima nástroj, jakým je phpminadmin, postupoval stejným vývojem jako je u software obvyklé. Nabalovat nabalovat a nabalovat není podle mě dobrý model. Zvětšuje se procento možných chyb a problémů. Používám phpminadmin protože je malý, jednoúčelný a to co umí, dělá dobře. Spíš bych se zaměřil na opravu drobných chyb, které má, hlavně z pohledu ovládání a dělal změny kosmetické. Mám upřímný strach že se bude nabalovat a bude z něj postupem času phpMyAdmin a co potom... to by byla škoda.
Děkuji, takový názor respektuji a do jisté míry s ním i souhlasím. Já také nechci přidávat funkce zbytečně, ale jen ty, které se opravdu budou hodit. Např. zobrazení polí ze závislých tabulek nebo našeptávač má podle mě velkou přidanou hodnotu, i když jenom pro někoho. Proto se ostatně tímto článkem ptám na názor uživatelů.
Máte na mysli nějaké konkrétní chyby?
Juraj Hajdúch:
Súhlasím, možno by bolo rozumnejšie riešenie:
phpMinAdmin for MySQL
phpMinAdmin for SQLite
phpMinAdmin for PostgreSQL
ako
phpMinAdmin for all :o)
Vždyť to je tak v článku popsané. Kromě phpMinAdmin for all bude existovat i phpMinAdmin for MySQL a ostatní: „půjde vytvořit i jednodatabázová verze“.
Juraj:
Nejak nechápem dovod pre používanie phpMinAdmin for all. Ostal by som len pri jednotlivých verziách.
Já třeba běžně pracuji s MySQL, ale pak si chci otevřít třeba soubor s bookmarky z Firefoxu nebo demo databázi dibi a najednou by se hodila podpora pro SQLite. Pro můj případ by byl tedy lepší jeden nástroj, i proto, že 2/3 kódu by byly společné.
Juraj Hajdúch:
(Berte s rezervou, nie som profesionál, ale zanietený amatér.)
1. novinka: osobne by som ju nerozvíjal; radšej admin jednej databázy, ale poriadny, ako admin pre XY databáz a nedotiahnutý.
2. a 3. novinka: užitočná vec, aspoň pre mňa, takže tú podporujem.
A teraz vlastné želania :o) respektíve námety na uvažovanie:
a) pouvažovať nad modulárnosťou, teda hľadať nejaký spôsob ako doprogramovávať a integrovať vlastné rozšírenia (extenzie, addony...); ja som si takto upravil tvoj produkt a zaznamenáva mi do externého TXT súboru SQL príkazy
b) podobne ako sa umožnilo pridanie vlastných CSS by sa mohli pridávať aj iné vecičky ako napr. jazyková lokalizácia, hlavička či pätička stránky, nejaké javascripty, "databáza" často používaných SQL príkazov uživateľa, aby ich len vyberal a nemusel ich písať a pod. a pod.
c) nakoniec som si nevšimol, či vôbec existuje nejaký návod na phpMinAdmin, ja ho síce nepotrebujem, ale zopár ľuďom, ktorých som s týmto produktom oboznámil a sú ešte väčšie lamky ako ja :-D by sa zišiel ako soľ ... no a to je asi jediná vec, na ktorú by som si trúfol :-) nakoľko vývoj phpMinAdminu sledujem a zopár mesiacov ho používam ako jediný admin pre mysql - dokonca som ho zaviedol aj vo firme - trošku spočiatku reptali, ale teraz by ho už nemenili
Malý exkurz: phpMinAdmin vs phpMyAdmin
samozrejme amatérsky urobené porovnanie na Win XP pro SP3 pri najnovších verziách triády Apache, MySQL a PHP, testy Min-u a My-u urobené po reštartoch počítača -> identické podmienky, série vždy rovnakých príkazov.
- rýchlosť spracovávania tých istých úkonov je u Min v priemere o 28% rýchlejšia ako u My (2 x 23 testov)
- štart Min-u (po zadaní prihlasovacích údajov) je až o 56% rýchlejší ako u My tzn. kým browser nezahlási "hotovo" (2 x 4 testy)
- (trochu srandy) pochopenie zdrojáku Min-u je asi o 1000...000% rýchlejšie ako u My :-D
(tie dve hodiny testovania som fak mohol asi využiť lepšie)
Díky za zajímavé tipy. Nad lepší modulárností se zamyslím. Kde jsem to potřeboval (v demu), tam jsem si vystačil s auto_prepend_file. Na druhou stranu má phpMinAdmin otevřený zdrojový kód, k dispozici je i kompilační skript napsaný v PHP, takže upravit zdrojové kódy a zkompilovat si vlastní verzi je triviální.
Návod by pokud možno neměl být potřeba. Pokud něco není dost intuitivní, tak to rád upravím, pokud by někde byla potřeba vysvětlivka, tak ji dám raději rovnou do aplikace. Kdysi jsem měl sepsané tipy pro jednotlivé stránky, ale nenašel jsem vhodné místo, jak je prezentovat.
Testy určitě zbytečné nebyly. Pokud je někde máš spolu s průkaznými výsledky, tak mi je prosím pošli.
Lubos:
Osobne bych podporu dalsich serveru udelal modularne.
Vyhledavani ve vice tabulkach potrbuji tak v 0.5% dotazu co delam, takze to nepotrebuji (kdyz uz pouziju MySQL Query Browser)
Naopak ten naseptavac by se mi hodil casteji, pokud by byl dostatecne rychly a flexibilni, ten bych potreboval tak u 2-3% dotazu :)
Vetsinu casu, kdyz uz delam nad databazi tak mam pri ruce graf kde je co a jak je provazano, nebo si to pamatuji v hlave...
1. už aby to bolo (PostgreSQL)
2. + 3. viac-menej nevyužijem
Skôr by som prijal našeptávač názvov stĺpcov z tabuliek (napíšeš tablename. a po chvíli sa zobrazí zoznam stĺpcov z tejto tabuľky, vyberieš si šípkami a enterom vložíš), prípadne aj tabuliek (asi na nejakú skratku, automaticky to asi nepôjde)
To ukladanie do súboru by sa mi občas hodilo, niečo ako tlačítko pamätať si dotaz, prípadne obsah textarey (uloží sa do session) + export zapamätaných do súboru(na server, na stiahnutie, ...).
Tiež by sa mi hodila podpora komentárov (--comment) v textaree, keď niečo skúšam, aby som mohol zakomentovať riadok príkazu a nie ho mazať a potom naspäť dopisovať.
Tak oni fungujú # komentáre, takže poslednú pripomienku beriem späť
V MySQL se komentáře uvozují posloupností '-- '. Stejnou logiku používá i phpMinAdmin.
Aha, tak tá medzera mi tam vždy chýbala, myslel som že to nefunguje...
Taky mě napadla ta modularita...
Jinak vzhledem k možnému vývoji po koupi Sunu se jiné DB dost možná budou hodit.
Líbila by se mi (nastavitelná) možnost aktualizace. Nevadí, že to nebude k dispozici za každých podmínek, ale pokud to je k dispozici, tak proč to nevyužít?
Moduly vs. úpravy: při aktualizaci se pozná, že moduly jsou lepší.
Juraj Hajdúch:
Dobrý postreh, nad budúcnosťou MySQL je teraz otáznik - možno by nebolo od veci pouvažovať nad nejakou jednostrannou PHP aplikáciu, čo by transformovala MySQL na nejakú inú databázu - pre istotu. :-)
Automatickou aktualizaci velmi rád přidám. Když vydám novou verzi opravující nějakou chybu, tak mi je líto lidí, kteří si toho nevšimnou a používají starou verzi.
Teď jen jak to technicky zrealizovat – stahování vzdáleného souboru z PHP dělat nebudu, protože je blokující a nemusí být k dispozici kvůli allow_url_fopen. Takže zbývá JavaScript – obyčejný <script src> při nedostupnosti serveru způsobí to, že prohlížeč zobrazuje nahrávací ikonu, takže zbývá událost onload.
Aktualizace by také měla upozornit jen jednou – uložení informace o zkontrolování aktualizace do session tedy nestačí a bude potřeba ji uložit do trvalé cookie.
I tak si ale říkám, jestli to není moc agresivní. Co si myslí ostatní?
Juraj Hajdúch:
Osobne by mi postačovalo, aby sa tam ukázala len ikonka/zvýraznený text, že je dostupná novšia verzia a pripojený link na download. To tam určite implementuj - teda pouvažuj, aby som ti nerozkazoval. :o)
Kontrolu nové verze jsem doplnil do SVN. Konfigurovatelné to není, spouští se to vždy, ale nová verze se kontroluje jen na stránce výběru databáze a používá se co nejméně rušivý způsob - informace o aktuální verzi se stahuje pomocí neblokujícího JavaScriptu a jen jednou za spuštění prohlížeče.
Co zobrazit obrázek resp. skript posílající obrázek (např.: s expirací jednoho dne), který by se měnil podle aktualní verze?
BTW: Je to spíš maličkost, hodil by se čas provádění dotazu.
Načtení obrázku taky zdržuje (prohlížeč se tváří, že pracuje). Musíme brát ohled na to, že phpMinAdmin nemusí mít připojení k Internetu nebo server může být přetížený, takže kontrola nové verze nesmí nijak překážet.
Čas provádění dotazu je už pár dní v SVN (zobrazuje se u SQL příkazu).
Přiznám se, že jsem poměrně dlouho phpMinAdminu odolával, protože jeho hlavní (prezentovaná) výhoda, že není třeba nikam nahrávat objemný phpMyAdmin, pro mě nebyla rozhodující (mám pro všechny weby jen jeden phpMyAdmin na svém počítači a i kdyby ne, nahrát víc souborů mi nedělá takový problém).
Nicméně stále jsem na minAdmina narážel v EDU 2000 ;) Ale teprve když ho v průběhu dvoudenního školení v hospůdce do nebes vychválil jistý Karel, použil jsem ho druhý den pro návrh databáze. Naostro, bez přípravy, v půlce školení, zcela neznámý produkt.
Dopadlo to tak, že phpMYadmin už nikdy v EDU 2000 nestáhnu! :-)
Nadchlo mě především to, že phpMinAdmin jde uživateli na ruku, je velmi uživatelsky přívětivý a ví, co obvykle programátor potřebuje. To je obrovská deviza, v oblasti open-source aplikací bych spíš použil slovo rarita.
(p.s. Jakube, kde se to v tobě bere? ;) Kup si iPhone, budeš spokojen).
Otázkou je, jestli phpMinAdmin je uživatelsky přívětivý jen náhodou, nebo jde skutečně o zamýšlenou a klíčovou feature. Pokud to druhé, měl bych celou řadu dalších nápadů a návrhů (z nichž asi nejdrsnější je změna názvu produktu). Pokud nejde o klíčovou vlastnost, tj. priority vývoje jsou jiné, pak budu moc rád, pokud se současná přívětivost udrží.
Prdlořeznictví Krkovička, n. p.:
Kdepak, phpMinAdmin byl od začátku vyvíjen, aby záměrně nebyl uživatelsky přívětivý. To je teďka nový trend. Žel, Jakubovi se to furt nějak nedaří, a ne a ne se tu přivětivost ze svého skriptu setřást (přestože od počátku přesně věděl, že ji samozřejmě nechce).
Ale tak to přece není. Uživatelská přívětivost není klíčovou vlastností většiny programů; a když je, zpravidla se jí zase nepodaří dosáhnout. Považuju proto za legitimní se zeptat např. tvůrců bugs.php.net, jestli ten web je tak šíleně antifriendly záměrně (aby se méně reportovalo) nebo nechtěně (tvůrci usilovali o opak).
Juraj Hajdúch:
Za jedno Vám dám, pán Grudl, za pravdu: že phpMinAdmin a phpMyAdmin sú až príliš podobné názvy - poniektorých ľudí to môže zmiasť. Chcelo by to nejaké svojrázne logo, vybudovať nejaký typický image produktu.
Jsem rád, že jsi vzal phpMinAdmin na milost. Všiml jsem si, že když jsi ho někde viděl nainstalovaného, tak jsi měl pocit, že jsem tam před tebou musel být já :-).
S nápady a návrhy samozřejmě sem. Přívětivost a přehlednost je zcela zásadním kritériem, nové funkce dodělávám pokud možno tak, aby nepřekážely.
O změně názvu mi říkáš den poté, co jsem za krvavé peníze koupil doménu phpminadmin.net? http://img43.imageshack.us/img43/2517/phpminadminplatba.gif :-). Ty vymýšlíš názvy kouzelné, takže bych se o změně možná nechal i přesvědčit. Pošli mi to prosím soukromě.
> Přívětivost a přehlednost je zcela zásadním kritériem
Tak to je super. Pokusím se dát postřehy dokupy.
K tomu názvu - nemám žádný nápad, jen jsem tě chtěl k přejmenování navést. phpMinAdmin je vtipný název pro minified verzi phpMyAdmina, jenže jak teď vidím (a ty potvrzuješ), ambice a záměry projektu jsou docela jiné. S názvem phpMinAdmina se těžko budeš etablovat jako plnohodnotná alternativa, lidi nebudou mezi značkama rozlišovat, ani vizuálně si člověk nemusí všimnout rozdílu; a ti, co rozlišovat budou, mohou považovat tvé počínání za cizopasení (= negativní názor).
Dobrý název nevymyslíš, ten napadne. Ale jen tehdy, pokud budeš nový název chtít...
Myslel jsem, že něco vysypeš z rukávu :-). Já teď taky trochu lituji, že jsem se chtěl proti phpMyAdminu vymezit a zvolil tak podobný název. Je to podle vzoru lynx, links.
Mě třeba docela dobrý název přijde Adminer, ale na to, na co jsem ho použil, se stejně hodí víc. V začátcích jsem si říkal, že by phpMinAdmin mohlo být takové lákadlo na Adminer, takže by byl docela příhodný název Adminer Lite, ale to se zatím moc nepovedlo.
Prdlořeznictví Krkovička, n. p.:
Ad 1) Toto znamená zesložitění celého projektu (nejen) co do struktury kódu, rozšíření na specifika všech uvažovaných databází, rozředění toho zápalu, který do phpMinAdminu vkládáš; a desítky potenciálních sémantických (dobře myšlených, špatně implementovaných) chyb. Takováhle rozšiřování a zuniverzálňování leckdy mohou být "až nad hlavu", myšleno tak, že se v tom programátor nakonec buď sám utopí, nebo se mu může stát, že podpora ze strany ostatních lidí vyhasne a celý projekt umře.
Ad 2) To bude fuška, ale jsou lidi, kteří to ocení - spojované dotazy nejsou zase tak vzácné. Btw. a co více než 2 spojované tabulky - co třeba takových 5? Víš, jak to udělat a všechny ty závislosti vyřešit?
Ad 3) Rozhodně pro ;-) Zkusil bych u malých rejstříků (do určitého limitu, pár stovek záznamů, což může být v reálném nasazení většina rejstříků) načítat rejstřík do paměti, "vyprsknout" ho do JavaScriptu výsledné stránky a našeptávání dělat bez nutnosti AJAX-komunikace.
1. Úplně souhlasím. Zpočátku jsem také vehementně tvrdil, že podpora dalších databází není cílem projektu a že rozdíly mezi databázemi jsou příliš veliké. Hodil by se mi ale nějaký šikovný správce SQLite databáze, proto jsem nad tím začal uvažovat. Rozředění projektu je velmi pádný argument, možná podporu ostatních databází ještě odpískám. Díky přípravě na SQLite jsem kód alespoň trochu restrukturalizoval, takže to bylo užitečné už tím.
2. Současný prototyp je takový, že k jedné hlavní tabulce lze připojit tabulky, na které se přímo odkazuje. Nepřímé vazby (odkaz ze sloupce v odkazované tabulce) zatím neplánuji.
3. Budu se držet AJAXu, aby se nezdržovalo načítání editační stránky. Tento AJAX se ale může prefetchnout ještě před tím, než člověk začne do políčka psát. Každopádně chápu, co máš na mysli, a děkuji za tip.
Jaký název? Snad ne iAdmin? ;-)
Kurník, zase mám pocit, že jsem na něco zapoměl?
Juraj Hajdúch:
Nestraš! :o) Som "alergický" na všetko, čo začína na "i".
Marty:
... na písmeno "n" :)
tondovo:
Já bych se přimlouval za podporu SQLite. Zkoušel jsem všechny webové administrační nástroje uvedené na sqlite.org a s žádným jsem nebyl úplně spokojen, proto raději automaticky používám MySQL.
Jan Garaj:
Z hľadiska užívateľskej prítulnosti by som navrhol doplniť pri dump-e db:
1.) označenie celého stĺpca akcií u tabuliek naraz
Napr. predefinované je myslím akcia u štruktúry tabuľky DROP, CREATE, avsak ja potrebujem iba CREATE, tak to musím žiaľ po jednom meniť pre každú tabuľku. Pritom bežne používam 40-50 tabuľkové db.
2.) tlačítko Export umiestniť aj pod výpis tabuliek
Keď vyklikám prípad 1, musím scrolovať naspäť hore, aby som to mohol submitnúť.
Podporu iných db vítam (SQLite, PostgreSQL).
Jakub Vrána :
V exportu se tabulky dají hromadně označit kliknutím do záhlaví tabulky. Zjevně ale pokulhává použitelnost, protože nejsi první, koho to nenapadlo. Jak tuto akci zvýraznit, mám ze záhlaví udělat odkaz? Nemohlo by být matoucí, že ve výpisu se odkaz používá pro třídění?
Tlačítko Export původně bylo dole, ale na žádost, ať ho dám i nahoru pro případ, že defaultní volby vyhovují, jsem ho tam přesunul. Teď vidím, že to nebyla dobrá volba – tlačítko jsem tedy zkopíroval.
Jakub Vrána :
Ze záhlaví exportu jsem udělal odkazy, což má ten vedlejší efekt, že hromadné označení funguje i bez JavaScriptu.
Jan Garaj:
Áno autor mal zase raz pravdu :-).
Na záhlavie tabuľky pri dumpe sa dalo klikať aj predtým. Teraz je to však už výraznejšie aj pre nás málo všímavých. A tiež chválim počin spraviť to cez odkazy. Dá sa to takto použiť aj bez javascriptu ako bolo spomenuté, čím sa zväčšila prístupnosť pre paranoikov, ktorí používajú NoScript.
Ďakujem tiež za Export tlačítko pod výpisom.
Martin:
Docela chybí možnost upravit více záznamů najednou. Teď lze provádět hromadné úpravy jen tak, že se provedená změna uloží totožně do všech vybraných záznamů. PhpMyAdmin umí udělat více různých změn naráz (zjednodušeně řečeno umí ukázat deset formulářů s editací různých záznamů pod sebou a všechny změny odeslat jedním submitem). Obrovsky to ulehčuje práci a šetří čas.
Výchozí css téma by mohlo být modernější, takhle to vypadá jako stránka udělaná před sedmi lety.
Jakub Vrána :
Stránku s deseti editačními formulářemi pod sebou dělat nebudu. To bych raději dramaticky zjednodušil editaci záznamu – vzhledem k tomu, že se při výpisu tabulky načítají všechna data, tak odkaz Upravit může pomocí JavaScriptu zobrazit editační formulář bez jakékoliv komunikace se serverem (kromě polí typu text, u těch by přenášení všech textů zdržovalo) a následně ho uložit pomocí AJAXu.
Alternativně by se mohl dát editovat přímo výpis tabulky – např. double-clickem do buňky by se tato buňka proměnila v editační políčko a změny ve všech záznamech by se potom uložily hromadně.
Kdy je vlastně potřeba editovat více záznamů najednou a přitom každý jinak? Já hromadné editace a klonování využívám, ale všechny záznamy upravuji stejně.
Co se stylu týče, tak mě vyhovuje, na domácí stránce je navíc několik skinů a snadno se dá dodělat další. Výchozí styl měnit nebudu, přijde mi zdravě střízlivý.
Prdlořeznictví Krkovička, n. p.:
My jsme v phpMyAdminu editaci více záznamů (a každý jinak) využívali často. Například (a uznávám, že to není nijak čisťounké řešení, ale přecijen:) u tabulky s nějakými texty, které psali jiní lidé, si jen tak zkusmo vyhledám nějaké typické pravopisné patvary ("kdyby jsme", "samozdřejmě", "verlyba", atd. atp.) a u záznamů, které "uvíznou" ve filtru, je pak opravím. To, že mě ostatní políčka nezajímají a zdržují, nicméně dávám za pravdu. Ale jak to navrhnout, aby se dalo u vybraných záznamů upravovat pouze jedno (popř. v druhém kroku jen ta vybraná) pole? Rozšířit fieldset "Upravit" (ten, co pod výpisem)? O fieldset se seznamem sloupců, včetně * na začátku?
Jakub Vrána :
Aha, to je rozumné využití. Editovat by se mohly ty sloupce, které jsou vybrané pro výpis (když už tam ta možnost stejně je).
Honza:
Líbilo by se mi, kdyby byla možnost přepínat mezi tabulko-editačním a data-procházejícím režimem i jinak, než odkazem v levé části s výpisy všech tabulek. Minimálně odkaz "Vypsat data" by se mezi ostatní odkazy v tabulkovo-editačním režimu hodil - někam nahoru (abych nemusel rolovat stránkou a hledat, kde je vypsat spojené s právě upravenou tabulkou)
Hever:
Dotaz do více tabulek uvítám.
Přimlouvám se ale za to, aby se defautlní hodnoty sloupce zadávaly tam, kde se sloupce editují. Např. chci přidat nový sloupec do tabulky a musím udělat tři kroky (přidat sloupec, nastavit default, updatovat všechny záznamy na default) namísto jednoho. Pro tuto operaci vždycky zapínám myAdmin.
Prdlořeznictví Krkovička, n. p.:
Prosím, prosím o implementování ještě jedné featurky - jak už někdo navrhoval předtím "u importu/sql příkazu při chybě zastavit" tak podobnou věc a sice "u importu/sql příkazu vypisovat jen chyby a varování". V poslední době jsme phpMinAdmin hodně používali na import většího množství dat - řádově tisíce dotazů v jednom souboru nebo bloku příkazů - a 1) vypsání stejného množství tisíc těchto stejných příkazů + stejného množství hlášek, že proběhly v pořádku + stejného množství příkazů ještě jednou v textovém poli přecijen na chvíli zpomalí server přitom, jak se stránka natahuje do dlouhé nudle. Ale především - je těžké v takto vypsané "nudli" projíždět a hledat případné chyby nebo varování - pokud se chci ujistit, že všechno proběhlo správně, popřípadě zjistit, co ne, tak by se tadyto hodilo jako ďas!
Řekl bych, že na implementaci to není nějak složité, ne? V podstatě jenom jedna podmínka..
Jakub Vrána :
Prozatím jsem to udělal tak, že jsem výpis příkazu zkrátil na 100 znaků. Pokud se pošle soubor, tak příkazy nestraší ani v poli pro zadání SQL.
Prdlořeznictví Krkovička, n. p.:
Uběhlo půl roku, … změnilo se v tomhle ohledu něco?
Ta možnost vynechání správně vykonaných dotazů by se (nejenom nám) šikla.
Jakub Vrána :
Nic se nezměnilo, pro vyhledání chybných dotazů je i nadále potřeba použít vyhledávání na stránce.
Vazba:
Už se nemůžu dočkat až bude podpora pro SQLite. Je nějaký výhled? :-)
Honzan:
phpMyAdmin:
Existuje nějaká možnost, jak mít pro editaci jen jeden sloupec?
Příklad: mám tabulku o cca patnácti sloupcích.
Chci v phpMyAdmin editovat pouze pátý sloupec.
Potřebuju ale při tom vidět na obsah většiny ostatních sloupců.
Cca 250 řádků.
Zatím to musím dělat tak, že zaškrtnu např. těch 30 ve výpise a dám je všechny editovat - ale nedá se v tom vyznat a snadno se udělá chyba.
Většinou, pokud potřebuji měnit nějaké hodnoty ručně, tak se jedná o jeden (či dva) sloupce. Bylo by tedy pohodlnější mít tabulku vypsanou "normálně" (tak jako při normálním prohlížení hodnot), jen s tím, že ten jeden požadovaný sloupec by místo hodnoty měl INPUT BOX.
Jde to nějak? Chystá se to?
Předem moc díky
Honzan hza AT post TECKA cz
cucací potřeby:
a nebo tou novou metodou - dvojklik do tabulky změní buňku na <input> nebo <textarea>.
Diskuse je zrušena z důvodu spamu.