SQL-DK 0.8

Vyšla první veřejná verze klienta pro relační databáze SQL-DK. Program je určen pro příkazovou řádku a použití v shellových skriptech nebo k ručnímu spouštění SQL dotazů. Podporuje číslované i pojmenované parametry dotazů. Díky formátovacím modulům může produkovat výsledky databázových dotazů v libovolném formátu. Viz oznámení verze 0.8.

11.1.2014 02:14 | xkucf03 | Zajímavý software

Komentáře

[Miriam]

podle mě naprosto zbytečná a nepraktická věc, ale uvidíme, jak se k ní postaví uživatelé.

[luky]

IMO todle je priklad aplikace, kde pouziti javy boli, protoze cas potrebny na start programu bude delsi nez jeho vlastni beh.

[xkucf03]

Zkoušel jsi to spustit? Jak dlouho to trvalo? Kolik ms. by pro tebe bylo přijatelných?

[potato]

Absolutní čísla jsou snad celkem jedno, když se srovnává poměr času stráveného spouštením javy a času, kdy program něco užitečného dělá.

Mne to zaujalo jako pěkný vhled do javího mindsetu. Nenapíšu jednoúčelový skriptík [třeba] v pythonu, který udělá SQL dotaz a naformátuje data do konečné podoby na několika řádcích. Napíšu shellový skript, který specifikuje dotaz pro javový program (s vlastním XML konfigurákem!), který ideálně vypíše tabulku jako XML, abych ji mohl prohnat přes XSLT, protože přece vládnu všemi těmito úžaznými technologiemi...

[x]

Já bych jenom dodal, že tohle není "javí mindset". Tohle je Franta.

[OldFrog {Ondra Nemecek}]

Mne to zaujalo jako pěkný vhled do javího mindsetu...

No ty argumenty v druhém odstavci jsou ukázkou nekonstruktivní kritiky. Pokud píšu desátý jednoúčelový skript, může se hodit nástroj, který ty jednoúčelovky zastřeší. Použité meziformáty (xml atd.) opět nejsou žádným argumentem - jejich použití může být přesně to, co se mi z nějakého důvodu hodí.

Není to spíš tak, že přínos programu může zhodnotit spíš ten, kdo ho pro své účely napsal (byť by tím účelem byl třea jen tréning)? A pokud se program hodil mě, může se hodit i někomu jinému.

[rADOn]

Co je na tom nekonstruktivního? Brambor má pravdu že tohle je typ úlohy na kterej je Java masivní overkill a čirý šílenství. Vymýšlet si nějaký umělý důvody aby to vypadalo "konstruktivně" je jen lhaní si do kapsy. Pokud totéž můžu nabouchat v pythonu nebo perlu lépe, jednoduššeji a efektivněji, tak je to jen intelektuální cvičení ve zbytečnosti.

[OldFrog {Ondra Nemecek}]

Správné je popsal vlastnosti daného řešení a nechat na každém, aby zhodnotil jeho užitečnost v konkrétním případě. Tak se oddělí obecné od individuálního. Nelíbí se mi útok na "javovský mindset", protože v určitém případě může být java nejvhodnější řešení. Útok na "javovský mindset" je pak nonsens a ničemu neprospívá.

Například pokud je java hlavní vývojová platforma týmu, na produkci běží vše v javě a nic jiného pořádně nikdo neumí, pak je volba javy pochopitelná. Nebo pokud má autor javu rád a chce se prostě jen pocvičit a výsledek poskytnout dalším ve stylu ber nebo nech být, pak je také těžko možné něco namítat. Podobných situací může být celá řada.

Naopak pro někoho, kdo umí python, má ho nainstaovaný atd. je vhodná volba python. A někdo, kdo potřebuje sql pro embedded zařízení s uClibC, zvolí třeba C.

Nekonstruktivní je tedy to, že se hodnotí za použití skrytých předpokladů (předpokládám, že ostatní jsou ve stejné situaci jako já) ale závěry se prezentují jako obecně platná realita (na toto je java nevhodná). A nekonstruktivní je dále navážet se do "mindsetu" někoho jiného aniž bych znal jeho motivy a situaci.

[rADOn]

…protože v určitém případě může být java nejvhodnější řešení…

Jo, jenže tohle je velice určitý případ ve kterém Java velice určitě není nejvhodnější řešení.

Například pokud je java hlavní vývojová platforma týmu, na produkci běží vše v javě a nic jiného pořádně nikdo neumí…

A nechce umět. A to je přesně "Javovský mindset". Všude jinde je normální že programátor který není idiot používá ty nástroje které jsou pro daný účel vhodné. Ne ty které jsou v jeho oblíbeném jazyce.

Naopak pro někoho, kdo umí python, má ho nainstaovaný atd. je vhodná volba python. A někdo, kdo potřebuje sql pro embedded zařízení s uClibC, zvolí třeba C.

Omyl. Kdokoliv není javista, (nebo trubka) si v první řadě všimne že ten program je z 90% shodný s klasickým řádkovým klientem. A že zbytek se dá zařídit nějakým tím awkem, sedem a podobně. Správný javista nejspíš řádkového klienta v životě neviděl, natož awk.

Nekonstruktivní je tedy to, že se hodnotí za použití skrytých předpokladů (předpokládám, že ostatní jsou ve stejné situaci jako já) ale závěry se prezentují jako obecně platná realita (na toto je java nevhodná).

Můj "skrytý" předpoklad je, že komplikovanější věci (na co nestačí mysql cli) dělám rovnou v pythoním interpretru, protože nabouchat připojení do databáze a spuštění dotazu je natolik triviální že to nestojí za nějaké programování. Můžu debatovat s rubisty nebo perlisty jestli se na tom dá ubrat pár písmen, ale vsadím koláč proti psímu sucharu že v každém z těch jazyků je to jednodušší než ten pitomý xml konfigurák, ani nemluvě o matlání se s JDBC.

Takže ano, troufám si tvrdit že na tohle je Java obecně platně pitomá. Jestli mi nevěříš (a budiž varován že jsem se javou nějakou dobu živil) tak nemusíš filozofovat o realitě, předpokladech a konstruktivitě. Stačí když vymyslíš nějaký případ kde to nebude platit. Něco co ten nástroj zvládne lépe než pár řádku skriptu. Do toho.

[pavlix]

Všude jinde je normální že programátor který není idiot používá ty nástroje které jsou pro daný účel vhodné. Ne ty které jsou v jeho oblíbeném jazyce.

+1

[xkucf03]

Všude jinde je normální že programátor který není idiot používá ty nástroje které jsou pro daný účel vhodné. Ne ty které jsou v jeho oblíbeném jazyce.

A platí to i obráceně? Je správné mít panický strach z programů v Javě a odmítat je bez toho, aby člověk zjistil, jak rychle fungují a zda je to pro jeho potřeby dostatečné nebo se zabýval poskytovanou funkcionalitou?

A že zbytek se dá zařídit nějakým tím awkem, sedem a podobně. … mysql cli

Prvotní motivací pro napsání SQL-DK byly dvě věci:

• abych mohl používat stejného klienta bez ohledu na DBMS a měl databázová spojení nakonfigurovaná pěkně na jednom místě
• podpora předpřipravených/parametrizovaných dotazů – oddělení kódu (SQL příkazů) od dat (parametrů)

a k tomu se začaly nabalovat další věci – důležitá je mj. abstrakce – oddělení formátování od samotného provedení dotazu → výstup v libovolném formátu

dělám rovnou v pythoním interpretru, protože nabouchat připojení do databáze a spuštění dotazu je natolik triviální že to nestojí za nějaké programování

Tenhle přístup taky někdy používám, ale časem zjistíš, že děláš pořád dokola to samé a že už tě to nebaví. Jde taky o ta nakonfigurovaná připojení (jména a hesla), která nejsou rozházená všude možně po kódu nebo v mnoha různých konfiguračních souborech… A taky to má trochu jinou cílovou skupinu – SQL-DK není určen jen pro programátory, cílem je nabídnout i pokročilejší funkcionalitu, aniž bys musel něco programovat, psát kód.

[rADOn]

A platí to i obráceně? Je správné mít panický strach z programů v Javě…

Takže, jestli tomu dobře rozumím, když umím více než jeden programovací jazyk a vyberu si ten ve kterém to zbastlím nejsnáze, tak je to projev strachu? Tak to budu těžkej případ pro Chocholouška.

BTW nevykládej si tuhle debatu jako znevážení tvého těžce vydřeného kódu. Naopak, vypadá to rozumě a bez javistických úchylek (až na ty konfiguráky v xml ). Ale to nic nemění na tom co pravil o javistické sebestřednosti Brambor výše: ubastlit to v pythonu je snažší a výsledek bude lepší. Což tu zatím nikdo nedokázal věrohodně rozporovat.

[axel]

Zde si dovolim pohled do enterprise prostredi. I kdybych nakrasne ovladal python, jako ze trochu ovladam, v zadnem pripade si v nem neudelam pomocne nastroje na projektu vyvijenem komplet v jave. Duvodem je, ze 90% java programatoru python neumi, nebude se ho ucit a nebude tedy schopna takove pomocne nastroje udrzovat nebo integrovat a pripadne je rozbije. Coz me trapi mnohem vice, nez zda je to reseni pametove efektivni, elegantni atd.

[pavlix]

Čímž si znovu připomínám, jak jsem rád, že nejsem enterprise ;).

[xkucf03]

Zde si dovolim pohled do XXX prostredi. I kdybych nakrasne ovladal YYY, jako ze trochu ovladam, v zadnem pripade si v nem neudelam pomocne nastroje na projektu vyvijenem komplet v ZZZ. Duvodem je, ze 90% ZZZ programatoru YYY neumi, nebude se ho ucit a nebude tedy schopna takove pomocne nastroje udrzovat nebo integrovat a pripadne je rozbije. Coz me trapi mnohem vice, nez zda je to reseni pametove efektivni, elegantni atd.

Dosaď si tam libovolné proměnné. Málokterá firma si může dovolit programátory, kteří umí padesát jazyků.

[Heron]

Málokterá firma si může dovolit programátory, kteří umí padesát jazyků.

Na druhou stranu základní znalost GNU / Linux je leckde považována za standard.

[Miloslav Ponkrác]

Možná v 1 % případů u programátorů ano. Ve zbytku to není třeba.

[pavlix]

Nevím, co je na mém komentáři natolik nesrozumitelného, že dostávám takovéto reakce.

[Miriam]

Ach jo, ty umíš tak hezky trollovat, že to ani není poznat Mně tady trolling žere jen paní ze Slovenska

[pavlix]

Tož mě jako trollování přijde to, co dělá Franta, možná se u paní učitelky inspiroval. Za mé příspěvky v diskuzních vlánkech, které považuje za své domovské, náhodně vkládá různé „vysvětlující“ příspěvky, které obvykle nemají s mým komentářem nic společného. Jen si nemůžu vybavit, co jsem mu vlastně udělal.

[xkucf03]

Tady ale nejde o to, jaký jazyk si vybral autor (to je jeho věc), ale jak se na to dívají uživatelé – někteří bohužel mají z programů v Javě panickou hrůzu a bojí se takové programy i nainstalovat. Chápu, že někdo může mít špatné zkušenosti s nějakými obludnými a špatně napsanými GUI aplikacemi, ale přijde mi to prostě hloupé mít takové předsudky ke každému programu v Javě.

[rADOn]

A z čeho ta "panická hrůza" asi pochází? Když přece JVMko je tak nenáročný a hbitý, tak nemůže existovat žádný skutečný důvod, že? Je to spiknutí! Lidi všude po světě se tajně domluvili že nebudou mít rádi Javu. Stojí za tím tajná organizace která šíří pomluvy, falešný benchamarky a dokonce tajně instaluje zákeřný viry sabotující JVMko. A do mýho počítače se dostali taky!

---

Srsly, tohle přesně ilustruje kde je chyba. Dokud javisti en masse budou odmítat připustit že nějakej problém existuje, tak zbytek světa bude odmítat uvěřit že ten problém je nebo bude někdy vyřešen. A javisti se před tou perzekucí budou ještě víc uzavírat do svýho malýho světa a dodávat si odvahu žvaněním o "enterprise".

[pavlix]

+1

Samozřejmě netřeba zapomínat, že s Javou pracují i lidé, kterých se tato kritika netýká.

[rADOn]

No to je právě ta tragédie že se to někdy týká i lidí o jejichž erudici mám vysoké mínění (včetně tady xfucka). To není otázka počtů (viz třeba php bastlí spousta lidí u nichž lze oprávněně pochybovat nejen o erudici, ale soudě podle dotazů v poradně občas i o základní gramotnosti, přesto php nikdo neostrakizuje) ale základní sebereflexe. Když bych před kolegy pythonisty prohlásil že python není pomalej jak spící šnek a začal v něm psát databázi, tak řeknou že jsem magor. A budou mít úplnou pravdu.

IMO sebereflexi zcela programově zničil Sun ("Java Everywhere"!) a už se nikdy nevzpamatovala.

[pavlix]

Už to tak vypadá.

[Miloslav Ponkrác]

„ubastlit to v pythonu je snažší a výsledek bude lepší. Což tu zatím nikdo nedokázal věrohodně rozporovat.“

Já se toho tedy ujmu. Jako člověk, který databázově v Pythonu programoval můžu napsat, že blbější API pro databáze, než je v Pythonu se fakt jenom těžko hledá. (http://www.python.org/dev/peps/pep-0249/)

Ačkoli Javu moc nemusím, tak JDBC a Python database API, to se nedá srovnávat. JDBC je promyšlené rozhraní, nad kterým někdo přemýšlel o mnoho lépe, než to co je v Pythonu.

Pokud bych měl dělat prográmek na běžnou databázovou aplikaci, dá se to skousnout. Pokud ovšem bych měl dělat aplikaci pro administraci databáze, pak bych řekl, že už je lepší cokoli jiného než Python.

Nehledě na to, že Java vás pravděpodobně nedonutí přepsat zdroják jen proto, že se autor Pythonu blbě vyspal, nebo zakoušil lysohlávky, a rozhodl se rozbít syntaxi jazyka po 17 letech a nekompatibilně ho překopat.

A to vůbec nemluvím o „kvalitě“ interpretru Pythonu, a kvalitě intepretru Javy.

Miloslav Ponkrác

[Heron]

Omyl. Kdokoliv není javista, (nebo trubka) si v první řadě všimne že ten program je z 90% shodný s klasickým řádkovým klientem. A že zbytek se dá zařídit nějakým tím awkem, sedem a podobně. Správný javista nejspíš řádkového klienta v životě neviděl, natož awk.

+1

Já jsem se do diskuse moc nechtěl zapojovat, protože nemám ve zvyku kritizovat cizí práci, kterou mi ani nenutí (takže je mi to jedno), ale když jsem si četl ten web, tak jsem si říkal, proč bych měl používat tohle, když psql zvládne totéž (+ se tomu dá pomoci standardními nástroji GNU).

nejspíš řádkového klienta v životě neviděl

Tohle se bohužel týká poměrně hodně lidí. Bez phpmyadmina, adminera, pgadmina apod jsou úplně bezradní a někteří dokonce tyto programy považují za tu db samotnou.

[Miloslav Ponkrác]

Někdy nechápu, proč účetní nedělají rovnou v řádkovém klientu, ale používají nějakou aplikaci typu účetní program.

Já jsme řádkových klientů různých databází viděl neúrekom. Ale na zobrazování dat je klasický řádkový klient obecně jakékoli databáze vysloveně nevhodná věc.

Na druhé straně nevidím důvod, proč nepoužít phpmyadmin, pgadmin, atd. Co je na tom špatného?

Jenom proto, že si plácáte játra a boucháte se do prsou, že používáte za každou cenu řádkového klienta? Jste king a velký vezír. A to je tak všechno.

[Heron]

Na druhé straně nevidím důvod, proč nepoužít phpmyadmin, pgadmin, atd. Co je na tom špatného?

Když se zeptáš takhle, tak na tom není špatného asi nic. Já jsem mluvil o něčem jiném. A to o stavu, kdy programátor tyto klienty považuje za tu DB samotnou a v hlavě si kolem toho vytvoří špatný model, jak věci fungují. S tímto se, bohužel, setkávám v praxi častěji než bych chtěl. Ti lidé často vůbec nevědí nic o klient server, nevědí nic o SQL apod. DB se nejlépe navrhují s tužkou a papírem, úplně bez kompu. A potom hezky poctivě ručně nahrkat create table v klientu. Až tohle ten člověk zvládne, tak si může vzít na pomoc pomocníka. Protože ví, co má dělat.

Někdy nechápu, proč účetní nedělají rovnou v řádkovém klientu, ale používají nějakou aplikaci typu účetní program.

Ale ta účetní by měla být schopná to spočítat kompletně bez programu. To je prostě základ. Ten program samozřejmně pomůže, ale člověk musí vědět v čem.

Jenom proto, že si plácáte játra a boucháte se do prsou, že používáte za každou cenu řádkového klienta?

Za každou cenu ne. Já jsem si tím prošel taky. V jedné chvíli, před spousty let (2006), jsem zjistil, že bez grafickýho udělátka nejsem schopný založit ani uživatele. Což se samozřejmě ukázalo v tom nejhorším okamžiku, kdy jsem toho klienta neměl a musel jsem něco udělat. Takže jsem prostě zatnul zuby, vyhodil všechny klienty a poctivě se to prostě naučil. Tehdy mysql. A zjistil jsem, že DB je úplně něco jinýho, než jsem si do té doby myslel. A toto byl ten zásadní krok, kterej mi pomohl se v tomto oboru dostat o dost nahoru. A přesně toto, na základně vlastní zkušenosti, radím ostatním.

[GeoRW]

Všude jinde je normální že programátor který není idiot používá ty nástroje které jsou pro daný účel vhodné. Ne ty které jsou v jeho oblíbeném jazyce.

vysledok je dolezitejsi ako nastroj, ktorym sa k nemu dospeje

[Miloslav Ponkrác]

„Můžu debatovat s rubisty nebo perlisty jestli se na tom dá ubrat pár písmen, ale vsadím koláč proti psímu sucharu že v každém z těch jazyků je to jednodušší než ten pitomý xml konfigurák, ani nemluvě o matlání se s JDBC.“

Vzhledem k tomu, že jsem s Python database API měl tu čest, tak prohlašuji a přísáhám, že JDBC je o dvacet tříd výše.

A to Javu v podstatě nenávidím.

Python bohužel má řadu špatných API, a to databázové k nim patří.

[Ivan]

Python neznam (znam "jen" Perl) v cem je jeho API tak hrozny? JDBC mi zrovna neprislo nijak genialni, hlavne to ze uz ma 4 verze. A navic myslim, ze verze 3 neni zpetne kompatibilni s dvojkou(kvuli praci s BLOBy).

PS: QtSql je taky docela hruza.

[Miloslav Ponkrác]

„Jo, jenže tohle je velice určitý případ ve kterém Java velice určitě není nejvhodnější řešení.“

V jednom aspektu je. Určitě se s Javou multiplatformně připojíte k největšímu počtu databázových strojů.

[OldFrog {Ondra Nemecek}]

Předmětem mého komentáře byl způsob argumentace. Ke vhodnosti javy jsem se nevyjadřoval. Odlišujte to, prosím.

[nope]

aaa, potrefeny javista se ozval

[xkucf03]

BTW: testoval jsem to i na Raspberry Pi – funguje to ovšem pro interaktivní práci to příliš nedoporučuji (na běžném desktopu ale není potřeba se toho bát)

[Miloslav Ponkrác]

Já bych se za autora postavil. Mně se to líbí. I ta dotaženost.

Upřímně řečeno nevím, proč by nutně musel být dodržován unixový ideologický postoj, že vše má dělat jen jednu funkci. Najmě, že kdybychom si posvítilo na řadu projektů, třeba takový emacs, ehm ehm.

Javu nemám moc rád, ale chápu, že autor ano.

Asi to nikdy nepoužiji, ale líbí se mi to (až na XML konfiguraci). Do dokonalosti chybí už jen stránkování dlouhých výsledků.

[xkucf03]

Díky. Ta unixová filosofie, že program má dělat jednu věc, je otázka granularity – co je to ta „jedna věc“? Někdo tu psal, že by radši udělal jednoúčelový skript v pythonu, který udělá všechno od přípravy dotazů přes dotázání databáze až po naformátování finálního výsledku. Já jsem to rozdělil na víc částí – dotazy si můžu připravit zvlášť, přes rouru nebo soubor je předat SQL-DK, ten se dotáže databáze a formátování řeší až formátovací modul nebo externí program napojený přes rouru.

Co se týče XML jako meziformátu – XML je první, protože k němu mám nejblíž, ale budou i jiné¹ formáty a formátovače – mám v plánu např. formátovač, který pro každý řádek spustí zadaný příkaz. Tedy něco jako xargs, ale bude to pracovat s řádky z databáze, ne s řádky textu, což má výhodu v tom, že uvnitř hodnot můžou být klidně znaky konce řádku a taky že se řádek neslije do jednoho textového řetězce – zachovají se hranice mezi hodnotami jednotlivých sloupců (předají se jako pole argumentů tomu příkazu) a půjde tam líp pracovat se vstupními a výstupními proudy (nasměrování do souborů nebo naopak STDIN načtený z hodnoty určitého sloupce) a s proměnnými prostředí (můžou být odvozené z hodnot sloupců).

K tomu stránkování: to právě není problém delegovat na jiný program, dá se to použít v rouře:

sql-dk … | less -R

(včetně barev) Možná doplním do toho shellovského obalovacího skriptu volbu, která tam to | less -R přidá, aby ho uživatel nemusel psát. Ale v samotném programu (v té javovské části) tohle řešit nechci, přijde mi to zbytečné.

_{[1] už takhle bylo první vydání docela velké, musel jsem to utnout, protože jinak bych to nevydal nikdy a pořád přidával nové a nové věci}

[retroslava]

To je tady z novinek blogís o vlastních projektech? Schválně sem pošlu někdy něco mojeho, až bude nová verze, a budu sledovat jak to dopadne.

[xkucf03]

Pošli. Rád si přečtu, na čem dělají ostatní.