Názory k článku
Doctrine 2: DQL

Pěkně a přehledně zpracovaný článek a vlastně i celý seriál, jak jsem dnes náhodně objevil. Mám jen jednu mírně OT poznámku, neboť mi to leží v hlavě: K čemu to je dobré?

Není to trochu krok stranou od rozšířených standardů (třeba klasického SQL, T-SQL, PL/SQL)? Kde se to dá využít? Kolik firem to používá? Jaké může být praktické uplatnění odborníka na Doctrine, příp. DQL, ve srovnání s rozšířenějšími systémy? Vyplatí se investovat do "hraní" si s takovým systémem?

Je to dobre k tomu, ze to obvykle vede k jednodussimu kodu, co obvykle vede ke kratsimu casu vyvoje/udrzby/na­vrhu, co vede ke snizeni nakladu.
K cemu to neni dobre: naopak to vede k dalsi vrstve abstrakce, co vede k vyssim narokum na HW zdroje.
V dnesni dobe casto plati ze naklady na vyvoj jsou radove vyssi nez naklady na provoz HW, takze se to vyplati (a taky kdyz se casem ukaze ze naklady na provoz neumerne rostou, tak je pravdepodobne ze projekt vydelava dostatecne zajimave penize ktere jde investovat do dalsi optimalizace a porad tak zustat na efektivnim ROI).

Ted asi zustane otazka jak to tedy setri ty naklady na vyvoj. Na dvou frontach, za prvy programator nemusi jit na uroven pouzite DB, takze nemusi resit drobne odlisnosti ruznych SQL, aplikaci nad Doctrine lze s malou mirou snahy vyvijet tak ze si dlouho udrzi prenositelnost mezi ruznymi DB (ta se obvykle ztrati az s optimalizaci na vykon, kde uz se vyplati zvolit konkretni DB a vyuzit jeji specializovane nastroje). Za druhy je to dalsi vrstva abstrakce, takze nemusite uvazovat jak vybrat z tabulky "artikly", jejich kategorie a jeste informace o autorovi a vzpominat jak je to v DB propojene a pak to predelavat ve chvili kdyz zmenite DB schemu. Proste vyberete ty 3 objekty pres vazbu definovanou v objektech a dal pracujete s instancemi objektu. Jestli pak treba vnitrne predelate jak je artikel prepojeny s autorem (treba z 1:1 na 1:N aby autoru mohlo byt vice), puvodni DQL dotaz a navazujici kod se zmeni jen minimalne a docela prirozene.

Investovat do DQL pokud umite SQL mi prijde jako zbytecny dotaz, nelibi se mi ten perex clanku, ze jde o neco uplne jineho, naopak bych rekl ze je to v podstate to same az na par drobnych detailu. Ten hlavni rozdil je v te vrstve, SQL je primo nad DB, DQL je nad definovanymi objekty.
Spis je otazka jestli investovat do nauceni nejakeho ORM. Ja myslim ze se to urcite vyplati, ne ze by to byl vselek pro vsechny typy aplikaci, ale i kdyby jste to nikdy nepouzil, znat ORM "styl vyvoje" dava zpetne dobry stupen nadhledu i pri tvorbe klasickeho SQL a navrhu DB schemat.

Nechápu - naučení DQL je otázka max. 1 odpoledne i pro podprůměrně inteligentního člověka se znalostí SQL...skoro se není co učit.

Je to pouze jiný způsob načtení entity, dá se takto načíst skupina entit najednou a šetřit výkon.

Proto nějaké otázky ohledně investic a využívanosti jsou irelevantní - i ten kdo nezná DQL a zná SQL a není úplná guma ten kód okamžitě pochopí

Toť (asi zjednodušeně) vše...

Možná předbíhám do dalšího dílu, ale zajímaly by mě dvě věci:

1. Jde nějak určit, přes který sloupec se provede spojení? Pokud jsou např. v tabulce Article sloupce Created_by a Updated_by, oba s vazbou na Person, tak jak určím, přes který se spojení má provést?

2. Jaké se položí dotazy? Když spojím třeba tři tabulky (Article, Article_tags a Tags), budou se přenášet všechna data Article (tedy třeba i kompletní text článku) u každého řádku výsledku (tedy pro každou značku) znovu?

Ptám se i proto, že mi DQL přijde ve srovnání s mým NotORM neuvěřitelně neohrabané a podle všeho i neefektivní.

1) To se určuje v dotazu u klauzuje JOIN, Honza to popisuje i v článku:

SELECT a, c FROM Article a JOIN a.category c 

Takže v tvém případě:

SELECT a, p FROM Article a JOIN a.createdBy p
SELECT a, p FROM Article a JOIN a.updatedBy p 

Podotknul bych ale, že v případě DQL to určuje pouze, jak bude entita naplněná pomocí eager loadingu. Pokud bys žádný JOIN neprovedl a pak zavolal `$article->getCreatedBy()`, Doctrine provede další dotaz na asociaci do DB v rámci lazy loading.

2) Pokud nezvolíš partial dotaz, pak ano. Načítají se zkrátka celé entity (bez navázaných asociací, viz první bod), protože ten dotaz tak položíš a tudíž se předpokládá, že celou entitu v konzistentním stavu chceš.

NotORM je nástroj na něco jiného. V něm se právě povinnosti psát nějaké stringy, které se pak přeloží na dotaz do DB, zbavuješ a necháš na nástroji, aby ti je generovalo samo. V DQL tyto stringy naopak psát chceš. Pokud ne, nepoužiješ DQL, ale nějakou z metod EntityManageru. Takže bych to neporovnával.

1. Omlouvám se za nepozornost a děkuji za nasměrování.

2. Já chci načíst celé entity, ale nechci, aby se přenášely víckrát. Existuje v DQL nebo v celém Doctrine nějaký způsob, jak databázi položit konstantní počet dotazů (tedy rozhodně nechci v každém průchodu cyklem pokládat další dotaz) a přitom nepřenášet data opakovaně (tedy rozhodně nechci text článku přenášet s každou další značkou)?

Nad DQL se pozastavuji proto, že podle mě jde z celého procesu eliminovat. Nevidím žádný případ, na který bych ho měl používat, a ani důvod, proč bych ho vůbec měl potřebovat.

Já chci udělat tohle:

foreach ($db->article() as $article) { // projít všechny články
    echo "$article[content]\n"; // zobrazit jejich text
    foreach ($article->article_tags() as $article_tags) { // projít všechny jejich značky
        echo "\t" . $article_tags->tag["name"] . "\n"; // a zobrazit jejich název
    }
} 

Chci, aby to položilo maximálně tři dotazy (klidně i jenom dva) a aby se text článku nepřenášel opakovaně. Dá se to dokázat pomocí DQL nebo Doctrine obecně?

1) ve třídě Article si nadefinuješ dvě many-to-one vazby na Person, jednu namapuješ na členskou proměnnou createdBy a druhou na updatedBy. V DQL potom rozhoduje, jestli po JOIN použiješ a.createdBy nebo a.updatedBy - interně se tedy joinuje podle sloupce, namapovaného na tu konkrétní proměnnou ve třidě Article (zřejmě jsi špatně pochopil, že "person" v "a.person" značí třídu, ve skutečnosti je to název proměnné ve třídě Articles).

2) SELECT t FROM Tag t LEFT JOIN t.articles a

je tohle neohrabané? :) Navíc se nemusím vůbec starat o vazební tabulku, kterou si Doctrine obhospodařuje sama.

Dokud za SELECT nedáš "t,a", tak se z tabulky Articles joinuje pouze sloupec, přes který je svázán s vazební tabulkou. Pokud pak chceš získat z vrácených instancí Tagů jejich články, jednoduše si je vytáhneš z jednotlivých instancí pomocí $tag->getArticles() a teprve až u nějaké instance článku použiješ nějakou metodu, např getter, tak se lazy loadují jeho data (ve skutečnosti totiž neobdržíš přímo instanci třídy Article, ale automaticky generovanou ArticleProxy, o čemž se asi ještě bude psát, nebo psalo). Navíc každý unikátní článek se načte jen jednou - entity manager si udržuje seznam již načtených entit.

Nepřipadá mi to neefektivní, ještě by se možná daly v rámci optimalizace po získání tagů ručně před-načíst všechny potřebné články pomocí SELECT a FROM Article a WHERE id IN (seznam_idcek_clan­ku), aby se při lazy-loadování nevolala spousta dotazů na jednotlivé články, ale na to už se asi každej vykašle :)

Aha, takže když chci dotazy pokládat efektivně (tedy ne při každém průchodu cyklem a nepřenášet stejná data opakovaně), tak mi s tím Doctrine nijak nepomůže a to ani když se uchýlím k DQL. Jediná možnost je udělat si to ručně skládáním seznamu IDček a přednačítáním článků.

Jaká je best-practice pro tuto primitivní úlohu (načíst třeba prvních deset článků a k nim všechny jejich tagy)? Mám na to využít DQL nebo ne? Bohužel tuším, že řešení bude kompromis mezi efektivitou a elegancí.

Položí se tedy jen jeden dotaz? Mohl bys ho sem prosím uvést? Rád bych si potvrdil tušení, že když má článek třeba deset značek, tak se celý text článku přenáší desetkrát.

A ještě by mě zajímalo, jestli by se to dalo rozšířit o nějaký sloupec ze spojovací tabulky (třeba důležitost značky pro daný článek). Tabulka article_tag by tedy měla tyto sloupce: (id_article, id_tag, priority). A podle toho priority bych to třeba chtěl seřadit a ve výstupu také zobrazit.

Děkuji za čas, který jsi mi věnoval.

Já moc nerozumím tomu, proč bych měl používat systém, který mi šíleně svazuje ruce, a když už mi něco dovolí udělat, tak se musím uchýlit k ručnímu psaní dotazů, které se stejně provedou neefektivně.

jestli se ti tady někdo pokusí znova zodpovědět ten dotaz aniž by ho pochopil, tak ho prosím už pošli do ... no ... někam

V mém poděkování nebyla špetka ironie, opravdu jsem Vaškovi vděčný. A myslím, že můj dotaz pochopil přesně.

Vašek: Nevím jestli nechápu pořádně tvůj dotaz, nebo ty odpověď, kterou napsal Koubas

mě přišlo, že si Koubasuvo odpověď pochopil, takže ten XOR ukazuje na Vaška )

To beru. Ale když to není efektivní, tak bych aspoň chtěl, aby to bylo elegantní. Abych mohl snadno vyjadřovat operace, které chci s daty udělat. Podle ukázek to ale spíš vypadá tak, že se operace vyjadřují dost krkolomně (mě vadí už jenom to, že na některé operace musím používat DQL) a stejně se provádějí pomalu.

NotORM je toho pravý opak - dovoluje elegantně získat data pomocí efektivních dotazů.

Počkej, Jakube - zajímá tě to řešení v Doctrine a důvody, proč to je tak řešené, nebo hledáš něco, k čemu bys mohl dopsat "NotORM to dělá mnohem líp!"? :) Protože jestli máš tu touhu vysvětlovat, proč to NotORM dělá jinak a v čem je to podle tebe lepší než jiné používané metody, tak máš dveře otevřené... ;)

Já bych chtěl Doctrine v první řadě trochu poznat. Říkám si, že když je z toho tolik lidí na větvi (v dobrém slova smyslu), tak to musí být pecka. Že v tom půjde psát přehledný a dobře udržovatelný kód, který nebude zbytečně ukecaný (čím víc kódu, tím víc chyb) a navíc bude v ideálním případě i efektivní.

A říkám si, že když je to tak velký projekt, tak určitě musí mít tyhle věci perfektně zvládnuté. A ptám se, protože si myslím, že jsem třeba jen něco přehlédl - že ten krkolomný kód, který se vykonává neefektivně, půjde napsat určitě nějak líp, než napadlo mě. Bohužel tomu ale nic nenasvědčuje.

Zatím si na srovnání určitě netroufnu, protože znám Doctrine málo. Až ho poznám lépe, tak to klidně můžu zkusit.

Zrovna tyhle čtyři operace mi přijdou tak triviální, že se snadno píšou i v prostém SQL. Z toho důvodu v NotORM původně ani nebyly. Pak jsem pro ně jednoduchou obálku přeci jen dodělal. Takže jestli tohle je silná stránka Doctrine, tak mě to moc nepřesvědčí.

Mě přijde zajímavé hlavně získávání dat, kde se zcela běžně pracuje s mnoha tabulkami a potřebuji nějak šikovně vyjádřit, co se s výsledkem pak má udělat. A chci, aby toto šikovné vyjádření bylo inteligentní - abych mu nemusel radit, jak má postupovat.

NotORM je nepoužitelný, už jenom kvůli tvýmu názoru na vyjímky - PHP4 už tu s námi dávno není.

Za prvé nechápu, jak s NotORM souvisí můj názor na výjimky, ale pro jistotu ho shrnu: "Když se pro zpracování chyb použijí výjimky, tak je nezbytně nutné je na správném místě ošetřit a nenechat je probublat zbytečně vysoko. Někdy může být jednodušší místo výjimek indikovat chybu návratovou hodnotou a PHP chybou."

Za druhé nechápu, jak NotORM souvisí s PHP 4 - NotORM vyžaduje PHP ve verzi alespoň 5.1 a naplno využívá jeho možností.

A za třetí uvedu, že NotORM respektuje způsob zpracování chyb nastavený v PDO - ten je u aplikací vhodné nastavit právě na výjimky.

Tady s tebou Jakube moc nesouhlasím. NotORM je efektivní z jednoho určitého pohledu, který tu rád propaguješ a je efektivní pro určitý vzor - který bych třeba já skoro nikdy nepoužil, minimálně bych jej neoznačoval jako efektivní.

1. Nedá se moc snadno najít scénář, pro který by NotORM bylo řádově pomalejší než nejefektivnější řešení. Někdy to může být o pár procent, prakticky ale nehrozí, že by NotORM "ulítlo", jako to je běžné v Doctrine. Pokud nějaký takový scénář znáš, rád se s ním seznámím.

2. Od vydání článku zde na Zdrojáku se NotORM dále vyvíjí, takže je pro určité scénáře možné elegantně využít i spojování tabulek.

Ano a tímto způsobem se rodí pojídači koláčů a místo jednoho SQL dotazu, co vytáhne potřebná data jedním vrzem se položí např. 94 SQL select dotazů. Ať žije lazy loading... Osobní zkušenost s opravováním aplikace nad Doctrine 1.2 ... Složitější věci jako intersect/except + vnořené dotazy nad množinou dat jsou fakt zážitek v DQL. A věc zvaná NativeSQL, nemá pomalu s SQL taky moc společného, zase podřízení DQL. A používání klíčových slov jako CURRENT_DATE a pod přestavuje problém ... Nutnost vytváření ID sloupce, který potřebuje Doctrine k životu? A skutečně stojí zato, pustit si logování SQLek co Doctrine vygeneruje ...

Možná Doctrine 2.0 je lepší, ale 1.2 mě neskutečně pije krev ....

2) Já nevim, ale já DQL chápu jen jako jazyk pro popis toho, co chci vydolovat za data. Že chci načíst články a k nim rovnou kategorie. To, jestli se to provede pomocí jednoho nebo dvou dotazů, bych považoval za implementační detail, se kterým nemá DQL nic společného. Takže pokud bys dokázal Jakube Doctriňákům obhájit svoje řešení, pošli jim patch :)

Pomocí DQL říkám, co se má vytáhnout za data, a pak ještě někde musím říct, co se s těmito daty má udělat. Druhý krok je nevyhnutelný, ten určuje logiku aplikace, ale bez prvního kroku bych se nejraději obešel. Já nevidím smysl v opravování DQL, protože podle mě to je zbytečná vrstva, která by neměla být potřeba. Já nechci tupý systém, kterému musím pracně říkat, jaká si má vytáhnout data (a i tak to ještě udělá neefektivně). Chci chytrý systém, který si data dokáže vytáhnout sám (ideálně efektivně).

... což je v praxi málokdy přípustné, takže se použití DQL často nevyhnu.

Tomu se snad nechce ani věřit. :-D Tak jak se to tedy řeší (omlouvám se, ale jsem líný kouknout do dokumentace)?

kdysi davno, je to uz 40 let se musel zavolat programator, kdyz chtel nekdo neco z databaze vytahnout. Ten pracoval podle jednoho stejneho principu. Zacal cist ve smycce nejake recordy z databaze podle pocatecnich kriterii a kdyz se mu nejaky zaznam libil, tak si nacetl potrebne atributy a kdyz to bylo nutne, tak podle atributu otevrel nejakou dalsi tabulku , zadal pocatecni hodnoty a ve smycce cetl jednotlive recordy. Kdyz se mu nejaky libil ...

To bylo samozrejme nepekne, malo flexibilni atd. blablabla ..

Proto se vymyslel dotazovaci jazyk, ktery jak cteme i zde je 'primocary' a 'lidsky', ze data z databaze vytahne i uklizecka. Tento jazyk je navic standardizovan a u vsech databazi stejny, neni-liz pravda. A protoze je tak primocary, tak proto se poradaji jiz 40 let skoleni, na katedrach informatiky se tato primocarost probira 2 semestry a nakonec se ty 'samozrejmosti' predvedou na zkousce. Jen tak z legrace se miliony lidi denne dotazuji na internetu v databazovach diskuzich a forech, jak nejakou tu 'samozrejmost' udelat.

A protoze je to tak vsechno jasne a primocare, tak se to vse zaneslo i do programatorske praxe, aby se programatori aplikaci nemuseli zabyvat pozadavky zakazniku (jak nudne ) nybrz optimalizaci dotazu.

A protoze je to vse tak jasne a primocare, tak se zavede dalsi abstraktni vrstva , ktera to vse jeste udela srouimitelnejsi a primocarejsi. A pak je take kazdemu jasne, ze neni mozne udelat insert, protoze EntityMap o tom nic nevi - to je jasne.

Vazeni, verte mi, ten cisar je skutecne nahý.

krásně si to napsal, jen co je pravda

někam si to uložim a budu tě citovat, jestli ti to nevadí

Možná na katedrách informatiky se SQL učí 2 semestry, nicméně já jej za odpoledne vysvětlím i uklízečce - což se např. o C nebo Basicu říci nedá. Bohužel řada programátorů nevěnovala SQL ani to odpoledne a raději věnovali několik stovek životů práci na bazmekách, které umožňují návrat k tomu starému a dávno překonanému principu a sladce snít o tom, že tabulka a pole jedno jsou.

Nezapomínejte na to, že miliony lidí se dnes a denně ptají jak udělat i primitivní iteraci v C nebo C++ a bohužel a v tom máte pravdu - řada vývojářů pracuje s něčím o čem vůbec netuší, čemu nerozumí a co by používat neměla - nejde jen o SQL - např. C, C++, C#, java, ...