devel.cz

Komentáře

• Kit : Takže databázi používáš jen jako úložiště dat? Nebylo by lepší použít NoSQL databázi, která už má ORM v sobě? — 2.11.2013
• matous.nemec : Pěkná odpověď, možná na nějakém projektu Doctrine použiji :) Píšete: "Napsat mappery mezi tabulkami a entitami je práce na dva týdn...generování tabulek se vším všudy, ...". To je ale dost dva týdny strávit nad mapováním, přijde mi rychlejší vytvořit DB třeba v phpMyAdminu, mít SQL v modelech přes něco jako třeba Dibi a tabulku mít zastoupenou v kódu třeba nějakým sourcem. To mi přijde přirozenější než převádět relační DB na objekty. Proč tedy rovnou nepoužít nějakou objektovou DB? — 2.11.2013
• matous.nemec : Ještě bych se rád zeptal, jak je to v Doctrine se složitějšími dotazy? Například select ze subquery. Našel jsem, že se má použít native query, takže pak budu mít část aplikace automaticky a v druhé části budu stejně psát SQL? — 2.11.2013
• Vašek Ch. : Matouši, to jsme se nepochopili :-). Za dva týdny lze napsat a odladit alternativu k Doctirne (tj. něco, co umí načítat data z databáze a vracet je namapované v podobě entit). Už jsem to dělal a není to tak těžké, aby to bylo použitelné, byť k plné funkcionalitě Doctrine by to mělo hodně daleko. A snažit se k tomu připsat ještě práci se schématy a jejich generování, to už je prostě opruz, do kterého by se mi nechtělo vůbec. Samozřejmě použít Doctrine v projektu je otázka instalace balíčku Composerem a napsání pár anotací. To je právě pohodlné ažaž a právě od tohoto by se mi nechtělo vracet nikam jinam zpátky. — 2.11.2013
• Vašek Ch. : Se složitějšími dotazy jsou v Doctrině jsou dvě možnosti: 1) Napíšeš dotaz v DQL, což je jazyk podobný SQL, ale je platformově přenositelný, anebo 2) napíšeš si native SQL query a Doctrina ti získaná data už jen namapuje. Ono nikdo neříká, že s Doctrine už nikdy nenapíšeš ani jeden SQL dotaz. S dobrou abstrakcí nad Doctrine jich ale můžeš budeš psát o 95 % méně, protože třeba u nás -- cokoliv se dá omezit JOINováním nebo podmínkami ve WHERE, získáme přímo bez použití dotazů. A ano, pokud chci vybrat např. průměrnou cenu všech objednávek, které jsou zaplacené, popř. čekají na platbu bankovním převodem, a zároveň v sobě mají nějaké produkty, které nesmí být vyreklamované a ještě jsme tyhle produkty ještě neobjednávali, takže nejsou na cestě na sklad -- tohle raději napíšeme dotazem i my, protože je to čitelnější a elegantnější. Ale, jak říkám, tohle je fakt jen 5 % dotazů, jejichž získávání výsledků jednak taky provádí Doctrina a jednak je i často mapuje, takže ve výsledku opět pracujeme s entitami. — 2.11.2013
• Vašek Ch. : Kite, to, že v aplikaci pracujeme s entitami místo tabulek, nemá nic společného s tím, jak je to uložené. Relační ukládání dat je moc fajn koncept, kterého nevidím důvod, proč bychom se měli zbavovat. Ano, teoreticky by nám to mohlo být asi jedno, ale jsme na relační databáze zvyklí a právě ty nativní dotazy, které přecejen sem tam je třeba udělat, raději budeme psát v notoricky známem SQL než něčem jiném. — 2.11.2013
• Kit : Považuji jazyk SQL za velmi propracovaný a elegantní nástroj pro práci s daty. Stavět nad ním nějaké univerzální ORM mi připadá jako hřích, protože stírá mnoho výhod SQL a značně omezuje způsob práce s daty. Přitom nesplňuje to, co slibuje - abstrakci nad daty. Stále musím definovat, které sloupce z kterých tabulek chci jak propojit. To umí elegantně udělat i jazyk SQL s mnohem jednodušším zápisem. Netuším, jak se např. v Doctrine dělají transakce, na to jsem zatím nenašel odpověď. Jak se v Doctrine zapíše, že chci nějakou hodnotu v tabulce zvýšit např. o 42? Jaký SQL dotaz to vygeneruje? — 2.11.2013
• Stefano : Ak si dobre pamatam tak doctrina ORM interne pouziva transakcie automaticky pri zavolani prikazu flush(). DQL(edit: nie DQL ale DBAL) na to ma prikazy a podporuje aj nested transaction http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/refere... — 2.11.2013
• matous.nemec : Vašek Chromický : To zní dobře, asi označím jako vyřešené a Doctrine někde vyzkouším, jen bych ještě měl jeden dotaz. Takže myslíte, že výhody Doctrine vyváží její větší paměťovou náročnost i to, že dotazy budou o něco málo pomalejší, díky tomu že se data musí mapovat? Když pak naroste počet webů s Doctrine, tak se to může negativně projevit právě na náročnosti na server, co myslíte? — 2.11.2013
• matous.nemec : Stefano : pěkné :) — 2.11.2013
• Stefano : Na zdrojaku http://www.zdrojak.cz/serialy/doctrine-2/ vychadzal serial o docrine 2. Je uz ale starsieho datumu a tak sa uz tam dost veci urcite zmenilo. — 2.11.2013
• Vašek Ch. : Kite, souhlasím, určitě se toho nezbavíš, jen v 95 % případů budeš mít s tou databází usnadněnou práci. To za to stojí, ne? :-) — 2.11.2013
• Vašek Ch. : My si v Symfony napsali anotaci. Nad kteroukoliv metodu napíšeme @Transactional, provedou se všechny operace v transakci. Co se výhod vs. hardware týče -- u malých webů to nepoznám, takže Doctrine, aby se mi dobře vytvářely. U větších webů to poznám, ale pravděpodobně bude výhodnější zaplatit trochu hw navíc a investovat peníze do rozvoje (do programátorů), který bude mít díky Doctrine snadnější práci. Pokud budu programovat Facebook, který poběží na tícovce serverů, tak tam stejně ani nepoužívám relační databázi pořádně ;-). — 2.11.2013
• Kit : 95 % práce je málo. SQL mi udělá 100 %. Volání dotazu v Doctrine a zpracování výsledku vypadá téměř stejně jako v PDO. Jen je v Doctrine spousta zbytečných deklarací navíc, které v PDO nepotřebuji, protože si je samo vytáhne přímo z databáze. — 2.11.2013
• Vašek Ch. : Jinak obecně... Tohle všechno je jen můj názor a moje zkušenosti. Podle mě mi to hodně rozšířilo obzory a za tu zkušenost to stojí. Promarněný čas to není. (Nemluvě o tom, že jsem s tím byl schopný naučit vybudovat web phpkáře největšího nováčka za pár dní.) Navíc na našich projektech používáme ještě vlastní mezivrstvu tzv. "filtrů" a "filter converter", což jsou jednoduché třídy starající se filtrování určitého typu entit. Příklad: Chci-li vytáhnout z databáze jen holky 18-25, co mají prsa B a C, udělám to jako $girlsFilter = new UserFilter(); $girlsFilter->setSex(User::SEX_FEMALE); $girlsFilter->setMinAge(18); $girlsFilter->setMaxAge(25); $girlsFilter->setBoobsSizes(['B', 'C']);. Tohle pak pošlu repository $userRepository->fetchList($girlsFilter), která za pomocí UserFilterConverteru překonvertuje tenhle čistý value objekt UserFilter na instanci Doctrine QueryBuilderu. A pomocí téhle instance QueryBuilderu pak Doctrine vytáhne všechna data a vrátí. Nemůžu si vynachválit :-). — 2.11.2013
• Vašek Ch. : Kite, ano, ale jakmile budu chtít přejmenovat sloupec users.boobs_size na users.breast_size, u mě je to jen otázka 1) přejmenovat atribut ve třídě User, 2) změnit jednu metodu v tom našem UserFilterConverteru, a už bude to fungovat, případně volitelně 3) všechna volání UserFilter::setBoobsSizes() přejmenovat na UserFilter::setBreastSizes() IDEčkem za 3 sekundy. Co u tebe? :-) — 2.11.2013
• Kit : Huh. Tohle všechno místo "SELECT name, photo FROM person WHERE sex='Female' AND age>=18 AND age<=25 AND boobSize IN ('B', 'C')"? — 2.11.2013
• Kit : Nevidím důvod, proč bych měl v databázi přejmenovávat sloupečky. Pokud to potřebuji v aplikaci, velmi dobře poslouží "AS". — 2.11.2013
• Vašek Ch. : Ano, protože až vedle budu chtít vybrat jen kluky, co mají výšku 160-180 cm, nebudu muset psát další dotaz. A až vedle budu chtít vybrat jen neaktivní uživatele, taky je to jen $userFilter->setInactive(true);. Dokud je počet různých podmínek menší než celkový počet různých čtení z té tabulky, jsem ve výhodě. A až moje přítulka porodí, zavolám jen $user->setBoobsSize('D'); $userRepository->save($user); místo abych psal další jednorázový SQL dotaz, který budu muset na věky věků udržovat. — 2.11.2013
• Kit : Tohle byl primitivní SQL dotaz. Nedovedu si představit, jak bys udržoval ty své filtry, kdyby ekvivalentní SQL dotaz byl na 50 řádcích. — 2.11.2013
• Vašek Ch. : Tohle se ti snažím vysvětlit. Jestli budu dělat dotaz na 50 řádků, nechám to v SQL dotazu. A pro zbylých 95 % případů použiju pohodlně svoje filtry. Už se chápeme? Já proti SQL nic nemám. Jen se mi architektura založená na volání metod v PHP udržuje lépe, než pracovat s tunou jednorázových SQL dotazech ve stringu. — 2.11.2013
• Vašek Ch. : PS: Nevidím důvod, proč v databázi nepřejmenovávat sloupečky. — 2.11.2013
• Kit : Když budu chtít vybrat kluky, tak jen přepíšu tu část dotazu, kterou budu chtít upravit. Pokud budu parametry měnit často, tak si je dám do formuláře a zjednoduším SQL dotaz na "SELECT name, photo FROM person WHERE sex=? AND age>=? AND age<=?" a zbytek dotazu doplním dle potřeby. Nejsem sice příznivcem slepovaných SQL dotazů, ale slepit je umím. Ostatně v tomto případě se dá snadno poslepovat vše za "WHERE". — 2.11.2013
• Kit : Není důvod přejmenovávat sloupečky v databázi. Správně se API vůbec nemá měnit. — 2.11.2013
• Martin Sura : "Není důvod přejmenovávat sloupečky v databázi" Ten byl dobrej :))))) — 2.11.2013
• Martin Sura : Jinak Kite doporučil bych Ti rozšířit si trošku obzory mimo sql a php? Ono ORM není úplně špatná věc a třeba ve světě C# ve spojení s LINQ, ti poskytne solidní abstrakci nad daty. (Ale to je OT) — 2.11.2013
• Kit : V C# nedělám, protože jede jen na Windows. — 2.11.2013
• Martin Sura : Není pravda :) — 2.11.2013
• Kit : Vím, že se to dá ladit i v Mono, ale nějak mi to v tom emulátoru nesedí. Když už potřebuji něco okenního, tak to napíšu v Javě nebo Pythonu. Když výkonného, tak ve Fortranu nebo Octave. Na zpracování textových souborů mám hromadu utilit. C# mi nechybí. Díky za zájem, zrovna se učím D. — 2.11.2013
• maryo : Tady je lehce zatrolleno :). Ale je fakt, že Doctrine je na většinu projektů IMO zbytečnej moloch. Doctrine má jednu killer featuru která mi na většinu projektů přijde jako zbytečnost. A to je abstrakce v podobě DQL. Taky bych to klidně psal v SQL. Ale to DQL a jeho vlastní parser má jednu velkou výhodu. Dá se z toho jednoduše vytvořit AST (z toho DQL stringu) a s celym tim stromem si pak pohrát v podobě DQL filtrů, AST walkerů, ... Nedávno jsem toho využil na REST API. http://stackoverflow.com/questions/19072686/sandboxing-dql-queries-in-do... Do API posílám requesty jako /users/?embed=contacts&query=contacts.firstName LIKE 'A%'. Samozřejmě je to odolný na SQL injection. (inspirace z JIRY https://confluence.atlassian.com/display/JIRA/Advanced+Searching) To s tím filtrováním nad Repository je fajn. Já jsem si napsal něco podobnýho podle http://www.whitewashing.de/2013/03/04/doctrine_repositories.html. A nakonec jsem to přesunul z Repository přímo do QueryBuilderu. $this ->createQueryBuilder() ->andMatch($specification1) ->andMatch($specification2) ->orMatch($specification3) ->getResult() ; BTW v REST API z toho těžim takhle. /users/?load=young,virgin,bigBreasts Kde young,virgin,bigBreasts jsou pojmenovaný callbacky třídy UserLoader implements SpecificationInterface. — 3.11.2013
• arron : Celé Doctrine je přece o tom, že místo asociativních polí pracuji s objektovou reprezentací dat. Není to o SQL atd. I v Doctrine můžu psát SQL dotazy, jak se mi líbí, ale právě můžu těžit z toho, že na konci dostanu hezký objekt. Je to jenom posun od procedurálního přístupu k objektovému, nic víc, nic míň. PDO sice také umí namapovat data do objektu, ale dělá to tupě a ještě blbě... — 3.11.2013
• Kit : PDO mapuje data do objektu tupě a blbě? Prosím o příklad. Doctrine nemapuje data vůbec, všechno musí programátor nadefinovat, aby to fungovalo. — 3.11.2013
• matous.nemec : Příklad ti neřeknu, protože PDO nepoužívám (možná pouze zaobalené v nějaké nadstavbě, takže se k použití PDO jako takové ani nedostanu). Je ale bez pochyby jasné, že mapování v Doctrine je na mnohem vyšší úrovni než v PDO. — 3.11.2013
• Kit : Chápu, něco to ORM dělat musí. — 3.11.2013
• matous.nemec : Někdo tu blouzní. ORM znamená Object relational mapping, což je vlastně úplně první co ti vyskočí na googlu. A pokud už chceš bezhlavě obhajovat svoje postupy a metody, tak to ti nikdo nebere, ale něco si přečti i o protistraně, pokud chceš mluvit o nějakých výhodách vůči něčemu. — 3.11.2013
• Kit : V klidu, už jsem v manuálu na 73. straně. Arron však napsal, že PDO mapuje data do objektu tupě a blbě. Proto mě zajímá, co PDO dělá tupě a blbě. ORM se dá dělat dvěma způsoby: Na straně objektové nebo na straně relační. Případně vhodnou kombinací obou postupů. — 3.11.2013
• matous.nemec : Jsem v klidu a navíc nepotřebuji poučovat o čem je ORM, to jsi asi špatně pochopil. Arron tím možná myslel, že je mapování v Doctrine, pak dlouho nic, ještě dlouho nic a pak se možná dá mluvit o nějakém mapování na objekty v PDO. To už jsi ale mohl zjistit z mého komentáře z dnes 13:17. Pokud to myslel jinak, tak musíš počkat až ti odpoví sám. — 3.11.2013
• Kit : Zkouším si z manuálu https://gist.github.com/kitsaels/cf302d892034d2f1a0f3 a zatím mě to moc nepřesvědčilo. Možná se na to dívám ze špatného úhlu, ale pořád mi to přes Doctrine připadá pracnější a nepříliš robustní. — 3.11.2013
• Stefano : @kit skor ako zacnes citat manual precitaj si knihu od Martina Fowlera - Patterns of Enterprise Application Architecture http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Marti... Potom mozno pochopis o com je orm. Doctrina pouziva principy, ktore su detailne popisane prave v tejto knihe. — 3.11.2013
• Kit : Podle prvního grafu z té knihy mohu ORM klidně odložit a pokračovat dál se svým PDO. Když jsem se začetl dál, tak vidím, že Martin Fowler, stejně jako já, sympatizuje s přesunem částí doménového modelu do uložených procedur. Z ORM se tím stane jen tenká vrstva, kterou si napíšu na pár řádek v PHP. Díky za tip. — 3.11.2013
• Vašek Ch. : Kite, doporučuju entity vytvářet pomocí anotací, ne YAML souboru. Viz entitu Article v sekci 7.2 stránky http://docs.doctrine-project.org/en/2.0.x/reference/working-with-objects.... — 3.11.2013
• Kit : Nevidím v tom výhodu, YAML je podle mne přehlednější. Alespoň nemusím koukat na stupidní gettery a settery. — 3.11.2013
• arron : @Kit: K tomu PDO: "Be warned of the rather unorthodox behavior of PDOStatement::fetchObject() which injects property-values BEFORE invoking the constructor - in other words, if your class initializes property-values to defaults in the constructor, you will be overwriting the values injected by fetchObject()!" To mluví docela za všechno :-) Ještě jsem se teda nedočetl, jestli ty property musí být public nebo to překouše i protected. Kdyby ne, tak potom bych fakt raději použil normální pole, než něco takového. Tak jako tak bych měl jistou potřebu nad to napsat nějakou obalovou třídu, aby mi třeba metoda query vrátila rovnou objekt/pole a nemusel bych nad výsledkem ještě volat nějaké další metody a tak. A to už je vlastně takovým základem k ORM :-). K tomu YAMLu: Já jsem původně strukturu databáze v Doctrine definoval právě v YMALu, ale štvalo mě, že něco někam napíšu a pak musím ještě někde jinde upravovat tu entitu a tak. Takže jsem skončil u anotací, protože to mám alespoň pohromadě a nemusím se pořád někam překlikávat. Co mě v Doctrine chybí (ale možná se toho dá nějak rozumně docílit), že musím definovat jak databázi, tak entity. To mě prostě nebaví, mě by se líbilo, kdybych k té třídě napsal ty anotace a dál bych se o to nestaral (a jenom přistupoval k setterům a getterům. To je věc, která se mi moc líbí na Lean mapperu. — 3.11.2013
• Kit : Tohle chování konstruktoru v PDO je výhodné. Nejprve se do objektu natáhnou data z SQL a pak se konstruktorem dopočítají závislé atributy, které v tom objektu chci mít. Ve chvíli, kdy je konstruktor hotov, mám objekt kompletní. Kdyby to bylo naopak, tak bys po načtení dat z SQL nemohl provést už žádnou akci a musel bys ji zavolat z vnějšku objektu. Musel bys mít další (zbytečnou) public metodu. Za běžných okolností se však konstruktor nepoužije vůbec. Třída si obvykle vystačí s jedinou metodou, jednou konstantou (ve které máš ten SQL dotaz) a několika privátními atributy. Můžeš do ní ještě přidat statickou metodu pro vygenerování SQL dotazu, pokud ho chceš nějak slepovat - obvykle to není nutné. Vše hezky pohromadě. — 3.11.2013
• arron : Beru to spíše jako zneužívání konstruktoru, osobně bych na nějaké dpočítávání použil gettery, které jsou přesně k tomuhle určené :-) — 3.11.2013
• Kit : V takové třídě jsou gettery a settery zcela zbytečné. Stačí jedna prezentační metoda. Ten konstruktor zpravidla není vůbec potřebný. — 3.11.2013
• arron : Tzn. jsou tam public properties. Jak říkám, v takovém případě už bych klidně použil asociativní pole, protože to už nemá s OOP nic moc společného a právě o OOP při používání ORM jde :-) — 3.11.2013
• Kit : Public properties nepoužívám, obvykle nepotřebuji gettery ani settery. Používám doménovou logiku, protože gettery a settery narušují zapouzdření objektů. — 3.11.2013
• matous.nemec : Kit : Možná ti to tak nepřijde, ale všiml jsem si toho u více komentářů. Prostě máš nějaký svůj způsob programování, ale ostatní to nějak neschvalujou. Někdo by se tedy měl zamyslet, buď všichni oponenti nebo ty, co myslíš? — 4.11.2013
• matous.nemec : Kit : Navíc fakt nechápu, že všechny komentáře, kde figuruješ se nehorázně až děsivě rozrostly. A přijde mi (možná je to jen můj názor), že je to z důvodu, protože oponuješ na všechno, co kdo napíše a cpeš tam své ne vždy správné a zaběhnuté řešení. Což je určitě dobře, když se lidé baví a oponují si, může z toho vzniknout pěkná diskuze, ale od tebe mi to přijde, jako že musí být tvé řešení vždy správně a není nic lepšího (také možná pouze můj názor). — 4.11.2013
• matous.nemec : Píšu to hlavně proto, že je tahle otázka již uzavřená, výsledek je, že i když je Doctrine náročnější na výkon, tak se vyplatí ji použít kvůli pohodlnosti, přehlednosti a taky třeba protože se programátor pak vůbec nemusí starat o databázi jako takovou, jsou tu i další argumenty pro. Pokud tu v komentářích vznikl nějaký nový dotaz, tak prosím vytvořte z těchto dotazů nové otázky, ať tu nevzniká takový "komentářový moloch". Maximálně je třeba odsud propojte linkem. Díky. — 4.11.2013
• MartinStepar : Kit : Ten příklad, co jsi uváděl výše (https://gist.github.com/kitsaels/cf302d892034d2f1a0f3) je psaný v Doctrine 1, která fungovala dost magicky a na jiném principu (tuším, že ActiveRecord). Jednička už je docela dlouho (roky) mimo, aktuální verze 2 funguje na jiném principu (Unit of Work, repozitáře, hromada podobných návrhových vzorů) a klade na entity méně požadavků. — 4.11.2013
• Kit : MartinStepar: Dal jsem si vygooglit Doctrine, první odkaz vypadal jako hlavní web a na něm byl manuál. Myslel jsem si, že je to bude aktuální, tedy dvojka. Zkusím se tedy podívat na manuál dvojky. — 4.11.2013
• Kit : Styl programování Martina Fowlera se mi líbí víc, než styl ostatních diskutujících. — 4.11.2013