Komentáře k článku

Doctrine 2: DQL

Dotazovací jazyk DQL (Doctrine Query Language) je jednou z nejsilnějších zbraní Doctrine 2. Kombinuje v sobě přímočarost dotazovacího jazyka SQL a nezávislost objektové entitní vrstvy modelu. Pokud berete práci s Doctrine 2 alespoň trochu vážně, bez DQL se rozhodně neobejdete.

Zpět na článek

42 komentářů k článku Doctrine 2: DQL:

  1. Jira

    K čemu to je dobré?

    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?

    1. Ped

      Re: K čemu to je dobré?

      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.

    2. Nox

      Re: K čemu to je dobré?

      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…

  2. Jakub Vrána

    Položené dotazy

    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. Ondřej Mirtes

      Re: Položené dotazy

      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. Jakub Vrána

        Re: Položené dotazy

        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.

        1. Ondřej Mirtes

          Re: Položené dotazy

          2) Nevím, jestli jsem tě pochopil správně, ale pokud si v Doctrine načteš z databáze nějakou entitu, Doctrine si ji uloží do IdentityMap a v rámci jednoho requestu, resp. života EntityManageru, pokud si o tu samou entitu zažádáš znova (ať už dotazem na asociaci, nebo $em->find($id), sáhne se po její referenci tam a nevolá se databáze.

          Pro zkoumání, jaké Doctrine pokládá dotazy, si ji doporučuji zprovoznit v Nette s Doctrine2Panelem (http://addons.nette.org/cs/doctrine2panel) a napsat si jednoduchou aplikaci s pár entitami a vyzkoušet si, jak se to chová při iterování atd.

          Pokud se lazy-loading v Doctrine zblázní a začne v cyklu pokládat dotaz při každém průběhu, je to právě chvíle pro DQL a použití JOIN, který načte navázané asociace pro všechny načtené entity v rámci jednoho dotazu.

          DQL poskytuje také alternativní (http://www.doctrine-project.org/projects/orm/2.0/docs/reference/dql-doctrine-query-language/en#select-queries:dql-select-examples) zápis filtrování (http://www.doctrine-project.org/projects/orm/2.0/docs/reference/working-with-objects/en#querying:by-simple-conditions) a jediný zápis řazení.

          1. Jakub Vrána

            Re: Položené dotazy

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

    2. Koubas

      Re: Položené dotazy

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

      1. Jakub Vrána

        Re: Položené dotazy

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

        1. manik.cze

          Re: Položené dotazy

          Nevím jestli nechápu pořádně tvůj dotaz, nebo ty odpověď, kterou napsal Koubas, zkusím to tedy na příkladu, který si dával výše:

          $q = $em->createQuery('SELECT a, t FROM Article a JOIN a.tags');
          // ted se polozi jeden dotaz, ktery vrati entity Article,
          // ktere v sobe jiz budou mit nactene svoje tagy (opet kompletni - tzn, i s nazvem)
          $articles = $q->getResult();
          foreach ($articles as $article) { // iterujeme nad entitami
              // vypisujeme text clanku (volame Nette properties nebo gettery)
              echo $article->content . "n";
              // iterujeme nad tagy, ktere souvisi s danym clankem (jsou v jeho kolekci)
              foreach ($article->tags as $tag) {
                  echo "t" . $tag->name . "n"; // a zobrazime jejich nazev
              }
          } 

          Dotaz se tedy provedl jen jednou na začátku a nadále už pracujeme jen s vrácenými entitami bez dalších dotazů.

          1. Jakub Vrána

            Re: Položené dotazy

            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.

            1. manik.cze

              Re: Položené dotazy

              Doctrine se defaultně ptá na všechny sloupce entity, takže je všechny po jednom vyjmenovává, dotazy jsou tedy většinou hodně dlouhé. Nemám to u sebe naprogramované, ale z analogické situace usuzuji, že by dotaz vypadal nějak takto:
              SELECT t0.id as id0, t0.content AS content0, …. , t1.id AS id1, t1.name AS name1, …. FROM article t INNER JOIN article_tag t2 ON t0.id = t2.article INNER JOIN Tag t1 ON t1.id = 2.tag

              S tím pojmenováním těch tabulek písmenky si nejsem jistý jak to generuje, mám to tu asi jinak než by to D. udělala, ale to teď nehraje roli.

              Takže myslím, že máš pravdu, že se článek přenese pro každý najoinovaný řádek. Jestli existuje nějaká optimalizace to nevím, asi by to mohlo jít přes ty parciální dotazy (nejdříve si načíst články a pak k nim dotáhnout pouze entity tagů), ale jak konkrétně by to vypadalo teď bohužel nemám čas zkoumat.

              Další příklad už jsem taky rozepisovat nebudu dopodrobna, myslím, že by to bylo složítější – jakmile bys ke spojovací tabulce chtěl přidat ten další parametr, tak pro tuto tabulku budeš muset udělat další entitu, která bude mít dvě asocoiace a tu tvojí hodnotu.

              1. Jakub Vrána

                Re: Položené dotazy

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

                1. jos

                  Re: Položené dotazy

                  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

                  1. Jakub Vrána

                    Re: Položené dotazy

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

                    1. jos

                      Re: Položené dotazy

                      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 )

                2. drevolution

                  Re: Položené dotazy

                  Já myslím, že hlavní motivací je to, že ti tenhle systém (Doctrine2) ve většině případů dává zapomenout na to, že s nějakou databází vůbec pracuješ a poskytuje ti prostě ukládání a načítání entit. Tenhle přístup se občas hodí, občas zase svazuje ruce.

                  Jakékoliv ORM nemá s efektivitou provádění dotazů co dělat. Nikdy to nebude tak efektivní jako SQL dotaz postavený pro konkrétní situaci.

                  1. Jakub Vrána

                    Re: Položené dotazy

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

                    1. Martin Malý

                      Re: Položené dotazy

                      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é… ;)

                      1. Jakub Vrána

                        Re: Položené dotazy

                        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.

                    2. drevolution

                      Re: Položené dotazy

                      Práce s entitami jako je:

                      • vytváření
                      • aktualizace
                      • mazání
                      • odpojování a opětovné připojování

                      a provádění toho samého na úrovni asociovaných entit mi elegantní určitě přijde. PHP programátorovi se to píše hezky a dokonce to i hezky vypadá. Jakmile se ale kód dostane nad trochu větší data, tak může způsobovat vrásky databázistům. Většina dotazů se v Doctrine dynamicky generuje, na což se špatně trefuje s indexy. Aby měl člověk alespoň trochu kontrolu nad tím, jaké SQL se bude provádět, na to mu slouží právě DQL. Tak to alespoň chápu já.

                      1. Jakub Vrána

                        Re: Položené dotazy

                        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.

                        1. Jaroslav

                          Re: Položené dotazy

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

                          1. Jakub Vrána

                            Re: Položené dotazy

                            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.

                    3. okbob

                      Re: Položené dotazy

                      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. Jakub Vrána

                        Re: Položené dotazy

                        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.

                    4. talpa

                      Re: Položené dotazy

                      Jakube nic proti tobe a NotORM, protoze se mi jako celek libilo, ale trochu jsem si s nim hral a videl i streva a zpusob jakym si obcas ziskaval DDL to byla taky kapitola sama pro sebe:) a nehlede na to ze tvuj pohled na databazi obcas nebyl az tak kosher, radeji pokladas dva dotazy abys nemel duplicitni hodnoty, no a vidis, Je to zas na ukor databazoveho stroje.
                      Proste si nevyberes.

                      1. Jakub Vrána

                        Re: Položené dotazy

                        Můžeš být prosím konkrétnější? Co máš na mysli „zpusob jakym si obcas ziskaval DDL“?

                        Pokládání více dotazů je vědomé rozhodnutí, které někdy databázi může prospět a někdy ne, viz http://www.notorm.com/#performance – asi nejdůležitější je, že tento způsob kladení dotazů je velice přátelský k tomu, jak funguje keš v MySQL, což databázi samozřejmě nesmírně pomáhá.

      2. Trpajzlík

        Re: Položené dotazy

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

    3. Honza Marek

      Re: Položené dotazy

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

      1. Jakub Vrána

        Re: Položené dotazy

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

        1. Cechjos

          Re: Položené dotazy

          …tak jednoduše Doctrine2 není zatím pro vás, co na tom dále řešit (*); jsou prostě programátoři, kteří s „tupými“ knihovnami rádi pracují. :) (* Krom posunutí Doctrine2 někam dál k implementacím ORM i z jiných jazyků – třeba Hibernate má „batch loading“, což vaši[ oprávněnou] výtku k počtu dotazů řeší.)

        2. manik.cze

          Re: Položené dotazy

          DQL ale vůbec používat nemusíš – není to ani standartní způsob. Obyčejně se používají jen repozitáře, o kterých tu Honza už určitě mluvil. DQL je pouze způsob, jak můžeš Doctrine lépe říct, co má kdy načíst. Pokud to neuděláš, tak důsledně dodržuje lazy loading a tzn., že když někde vypisuješ něco v nějakém foreach, tak by to typicky položilo spoustu dotazů.

          1. Cechjos

            Re: Položené dotazy

            Sice jsem nepsal o DQL, ale ad repositories – ve kterých na DQL stejně dojde, nebudou-li stačit metody pro nalézání entit. To, že na něj dojde, ale neberu jako minus; nevadí mi a naopak DQL beru jako standardní způsob pro získání kolekcí, na které základní repozitáře nestačí. (Koneckonců i Doctrine2 QueryBuilder staví DQL dotazy (což už se mi tolik nelíbí, ale pokud je to tak rychlejší než naopak, pak budiž).)

            Aneb jde spíše o to, že existuje nějaké DQL, ale že Doctrine2 nepokládá zrovna ideální dotazy / neposkytuje způsob, jak dotazování více ovlivnit. // Ale samozřejmě chápu, že se D2 stále vyvíjí, takže se třeba ještě něco v tomhle směru změní.

            Ještě ad Hibernate, aby bylo vidět, jak to řeší on:

            http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.html#performance-fetching-batch

  3. Ot@s

    Není možné vytvářet nové záznamy pomocí INSERT

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

  4. backup

    verte mi, cisar nema skutecne zadne saty

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

    1. jos

      Re: verte mi, cisar nema skutecne zadne saty

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

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

    2. okbob

      Re: verte mi, cisar nema skutecne zadne saty

      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, …

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3358