Názory k článku
Doctrine 2 a NotORM - videotutoriál

> 8. Sloupec přidaný do entity se při aktualizaci schématu nezařadí na
> správné místo, ale umístí se až na konec tabulky.

Asi kompatibilita s PostgreSQL :) Pg dokaze pridat stlpec iba na koniec tabukly a jedina moznost ako zmenit poradie stlpcov je CTAS (create table as select) a potom drop povodna a rename.

Prvy bod aj mne pripada ako blbost a rozmaznanost autora. Koniec koncov to vytyka aj vsetkym ostatnym frameworkom? A co CMS systemy?

Hups, reakcia pod nespravny prispevok.

jak člověk zjistí jaký je správný místo pro sloupec?

a proč na tom vůbec záleží?

Na místě záleží hlavně proto, že když mám nějaké podobné sloupce vedle sebe v entitě, tak je chci mít vedle sebe i při výpisu z databáze. Druhým důvodem může být nepatrná výkonnostní optimalizace (za určitých podmínek může být výhodné dát sloupce s pevnou šířkou na začátek tabulky a varchar na konec tabulky).

K výkonu: to může udělat DB sama (logicky bude mít sloupce poskládané tak, jak je požadováno, ale skutečné pořadí bude s ohledem na výkon).

A dělá to nějaká?

Navíc si nejsem jist, že přeskládání z fyzického do logického uspořádání bude zcela zadarmo, ale to je detail.

Nevím, ale mohla by. Do střev jednotlivých DB jsem se nedíval. Ale přesklávávat kvůli výkonu pořadí sloupců mi přijde jako taková mikrooptimalizace, která není hodna toho, aby se tím zabýval koncový programátor.

Zvlášť když ten koncový programátor používá ORM :-)

(tím nechci říct, že ORM je špatné, taky ho někdy používám, ale je to prostě takové kácení lesa – zatímco tyhle optimalizace jsou jen létající třísky – řešit je v takovém případě nemá cenu)

jo ten výkon, to sme tu (v háku) vlastně řešili před časem ... jak tu někdo psal, když už to může bejt taková výhoda, tak by se o to měla starat databáze, ne její uživatel

... tak je chci mít vedle sebe i při výpisu z databáze ...

to je nějakej špatnej vtip, ne? výpis záleží na pořadí atributů v selectlistu. pro ty kdo používají SELECT * FROM omg.wtf máme širokou škálu sebevražedných prostředků.

napriklad pri vypisu pres myphpadmina ze?

ha ha ha, a to je chyba databaze, ze phpadmin neumi zmenit poradi sloupcu?

proc by poradi menil? je vypisuje tak jak sou

no to je těžkej kalibr mezi argumentama

nechte si svoje pseudoproblémy, mě je to fuk

Na tuhle snusku blbosti uz reagovali autori Doctrine na Twitteru. 1 a 2 jsou naprosty pitomosti, dal uz se mi to cist nechtelo, pripada mi to jako ten samej list jako na tech vasich strankach. Mimochodem Doctrine se taky minifikuje a na symfony vubec nezavisi.

Odkazy na reakci autorů Doctrine a minifikovanou verzi by nebyly?

Taky bych se o ně přihlásil.

Reakci hlavního vývojáře Doctrine jsem zveřejnil u sebe na blogu.

O existenci minimalizované verze Doctrine nic nevím.

A část Doctrine na části Symfony samozřejmě závisí.

Tady mi přijde, že to záleží na úhlu pohledu jestli to je "část D2 závisí na Symfony" nebo "pro Symfony má D2 nějakou tu vychytávku navíc"...

Na Symfony závisí Doctrine Tools. Obejít se bez toho samozřejmě dá (i když to trochu bolí), ale vzhledem k tomu, že je část Symfony součástí distribuce, tak je závislost jasně přiznaná a nepovažoval bych za chybu, když by na Symfony začaly časem záviset i další věci.

Čo je to Symfony? Pretože Potencier začal písať jednoúčelové komponenty. To že sú v namespace Symfony ešte neznamená, že to závisí na Symfony Frameworku. A to, že je v doctrine Console použitá z potencierových Components, tiež nie je na škodu. Tuším aj YAML parser je použitý potencierov. Ale to mi príde ako, že mi vadí, že s NotORM potrebujem mať v php PDO ak chcem pristupovať k DB.

Zdravím,

tohle srovnání se mi velmi líbí. Je fakt, že Doctrine mě celkem zklamala, hlavně nutností používat DQL prakticky všude.

Jen když už se píše takovéhle srovnání, co takhle přidat pár slov o Nette\Database, aby byly vidět výhody/nevýhody této novinky oproti NotORM a Doctrine?

Nette\Database instanceof NotORM

Jednosouborové verze ocení programátor snad jen v momentě, kdy aplikaci potřebuje ručně nahrát někam na FTP. A to je IMHO způsob, který se dneska už u středních projektů (na které se už Doctrine hodí) příliš nepoužívá. Ve všech firmách, se kterými spolupracuji, je deployovací strategie taková, že je mi v důsledku úplně jedno, jestli se nějaká knihovna sestává z jednoho souboru či ze 333.

Výkonnostně je to něco za něco, konkrétně větší paměťové nároky za trochu lepší čas zpracování, takže z tohoto pohledu se IMHO nedá říct, že by minified verze byla něčím kategoricky lepším.

Tohle bych určitě nezmiňoval jako nějaký zásadní nedostatek, já myslím, že Doctrine se v tomhle směru chová úplně standardně.

Čemu vlastně vadí nahrávání většího množství souborů přes FTP? Možná to kvůli režii trvá o něco déle, ale to je snad vše.

Pokud se web nemá po dobu nahrávání chovat podivně (házet chyby a tak), tak se soubory musí nahrát do jiného adresáře a po kompletním nahrání na to předělat odkazy (třeba v include). Když by se jen postupně přepisovala stará verze, tak bude půlka souborů stará a půlka nová a s největší pravděpodobností dojde k nějaké chybě.

Naopak u jednoho souboru ho stačí při kopírování zamknout (pokud to jde) nebo nahrát pod jiným názvem, a pak už ho jen přejmenovat.

To je sice pravda, ale to je problém většiny updatů.

Totéž jde udělat i s adresářem (který obsahuje klidně stovky souborů), ne?

To spojování do jednoho souboru má IMHO spíš smysl u věcí, které se posílají na klienta (JS, CSS, obrázky), aby se neposílala spousta HTTP dotazů, ale jen jeden a vrátil se jeden velký soubor. U souborů, které zůstávají na serveru, je mi to celkem jedno.

V jakém filesystému a jakým příkazem jde přejmenovat adresář tak, že když už starý existuje (plný souborů), tak se atomicky smaže? Když to udělám ve dvou krocích (smazat starý, přejmenovat nový), tak zase bude existovat chvilka, kdy aplikace nepoběží. Když nechci kvůli nové verzi měnit zdrojáky, tak se to dá vyřešit ještě symlinkem, ale bez toho podle mě spolehlivě ne.

U klientských věcí to má samozřejmě ještě zásadnější význam, ale i na serveru to pomáhá. David Grudl na školení ukazuje výsledky benchmarku běhu Nette ve verzích 1) Minimalizovaná verze, 2) Všechny soubory, 3) Selektivní vložení jen použitých souborů (autoloader) jak A) S akcelerátorem, tak B) Bez něj. Nejlépe vychází právě minimalizovaná verze. Diskové operace prostě taky něco stojí.

No a NotORM má minified verzi? Já jsem ji ještě neviděl a na githubu zdá se také není. Navíc osobně zvládnu rychleji provést dvakrát za sebou přejmenování složky (ve kterých je XYZ souborů), než nahrát celý NotORM. Takže při přejmenovávání složek bude můj deployment Doctrine 2 rychlejší než Tvůj deployment NotORMu. :)

Podle mě je to s tou chvilkou, kdy aplikace nepoběží, zde vyhrocené do extrému (prostě se našel nějaký argument, na kterém se teď lpí). To, že taková chvilka existuje, je přirozené a většinou ji neodstraní ani minified verze. Uvedu příklad: updatuji minified verzi Nette. Nahraji ji na server, ale pak stejně musím ještě promazat cache RobotLoaderu a šablon (zkráceně adresář temp). Zase vznikne zhruba 5 vteřin, kdy se aplikace možná nebude chovat korektně.

Jak se to řeší u kritických systémů?

1. Včas uživatelům oznámím, že tehdy a tehdy dojde ke krátké odstávce systému z technických důvodů.
2. V danou chvíli se nahodí maintenance mód a na pozadí se provedou úpravy.
3. Úpravy se otestují v produkčním prostředí (tenhle krok ve svých úpravách IMHO úplně ignoruješ, což je podstatný nedostatek).
4. Až když je vše OK (a když je vše předem dobře připraveno, jsou dostupné automatizované testy a pdobně, jedná se o sekundy), systém se opět zpřístupní.

Nevěřím, že nějaká minified verze čehokoliv dokáže zjednodušit tento proces.

Souhlasím, že zabývat se tím je úplná ptákovina, a s tvým řešením souhlasím.

Já minified verzi používám raději z důvodu, že při přenosu na ftp se mi občas jeden/několik souborů nepřenese. Pak složitě hledám proč něco nejede...

Chce to pouzivat spolehlivy klient, napr. FileZillu.

Škoda jen, že textový soubor přenesený FileZillou mívá vložen prázdný řádek mezi každé dva řádky, což je autory programu považováno za feature, nikoliv bug.

linux, simlink. a opravdu, to ze mam 100 tabulek, 2M zaznamu, tak to, ze mam x trid v x souborech je to posledni co me trapi, kvuli tomu mi fakt server swapovat nezacne.

a jsou opravdu jine moznosti jak urychlit app nez komprimovat php do jednoho souboru!!!

Příště bych uvítal videa ve formátu WebM nebo Ogg/Theora, je to takové přátelštější a lépe se to přehrává. (aneb o moderních technologiích nejen psát, ale i je používat)

Nejsou to videa, jsou to "odklikávací" videocasty s předdefinovanými pauzami.

aha, mně se to totiž nepodařilo zobrazit vůbec, asi nějak zlobí Flash (mám 10.1.102.65), přitom třeba videa na YouTube nebo jiné flashe většinou fungují.

doctrine:
- minimalizované verze
+ proč by nešla doctrine minifikovat? proč by se měla minifikovat?
+ když použiju na deployment git tak je mi jedno jestli má projekt bžilión souborů nebo 10
+ FTP? fuj fuj, málokterý server, který utáhne doctrine má povolené ftp...

- Část Doctrine závisí na části Symfony...
+ doctrine má vlastní loader, všechny potřebné třídy jsou prefixované Doctrine/ a při použití loaderu zvlášť pro doctrine a zvlášť pro symfony je to úplně irelevantní

- Při zadávání informací pomocí anotací je velmi snadné udělat překlep, o kterém se nijak nedozvíme.
+ cli orm:validate-schema

- Pokud chceme s vazbami mezi entitami pracovat obousměrně, tak je také musíme na obou stranách ručně definovat.
+ to je nevýhoda, jen pokud v ní někdo nevýhodu chce vidět

- Zcela zásadně mi vadí, že Doctrine 2 pokládá dotaz při každém průchodu cyklem, to je zabiják výkonnosti.
+ DQL

- Pokud chceme udělat něco jen maličko složitějšího, tak musíme použít jazyk DQL...
+ to je nevýhoda? je sice pravda, že by to mohli trochu více optimalizovat, ale DQL imho není těžké a stejně mám všechny definice v modelu a jenom volám funkce.

- Při spojení tabulek, které DQL elegantně podporuje, se stejná data přenáší opakovaně...
+ generuje to klasické SQL, do teď to nikomu nevadilo, dotazy jdou napsat i tak, aby byly více efektivní :)

- Z mého pohledu se ten úplně největší problém projeví v případě, kdy se rozhodneme do vazební tabulky přidat sloupec s nějakou informací...
+ nevidím problém, přidám sloupec do entity, zavolám v cli orm:schema-tool:update a přidám obsluhu do modelů

- generování schéma
+ proboha kdo by to dělal ručně? Myslím si, že Honza na to prostě zapoměl, nemyslím si, že by záměrně nutil čtenáře, aby si sami vytvářeli tabulky. To by byl sadismus :)

notorm:
- Kód je velmi snadno modifikovatelný – pokud chceme např. setřídit záznamy...
+ v doctrine je anotace na výchozí řazení entity, což pokryje velkou část výpisů

- Pokud z tabulky nepotřebujeme získat všechny sloupce, tak to v Doctrine 2 můžeme zajistit pomocí DQL...
+ v doctrine jsou na něco podobného proxy třídy, kterým se předá pouze ID a daty se naplní až při přístupu k jejich vlastnostem, proto taky doctrine doporučuje používat private a protected properties, aby mohla gettery a settery překrývat lazy loadingem

závěr:
Proč se srovnává not-orm (extrémně výkonná knihovnička, na čtení databáze) a pravé ORM (tlustá mrcha co mi dovolí nestarat se o databázi, ale jen o moje objekty)? Na malý webík, který potřebuju mít rychle použiju Nette a možná bych se o podíval na Nette\Database, ale ještě tak minimálně půl roku budu skeptik. Na velký projekt použiju Nette a Doctrine2, abych se nemusel starat o mapování a další otravné opakující se práce, ale napíšu entity, napíšu služby (a) model a mám vystaráno :)

+1

+ Kód je snadno modifikovatelný také, kdeco lze nastavit, kdeco lze přidat - drivery, parsery, typy sloupců, funkce DQL, walkery, listenery...

Naprostý souhlas, to notorm není nic jiného než zapisovat selektování dat pomocí šipeček a závorek a nevím čeho. Kdo nemá rád sql ať si to klidně používá, ale kdo chce objektový mapper pro entity a modely, tak ten použije ORM, ať je to Doctrine nebo něco jiného.

naprosty souhlas.

clanek jsem vubec nechytl. veci jako ze to ma jiny poradi sloupcu nebo ze to nema jeden 10MB php soubor? a komu to vadi? ja myslel ze jsou tu programatpri, vzdelani lidi a ne banda blondyn...

si prozen zdrojak nejakym tulem at to z toho udela 1 soubor ne? docela chapu ze vec typu notORM se ti vejde do jednoto souboru, ale ja v tom aplikaci psat fakt nechci (pomer zavorek a sipicek v pomeru limitu a wheru je pro me moc velky :), to je zase pro me neco jak opustit namespace a tridy a prstit vsechno do jednoto php i s html s nazvem index.php)

Doctrine konkrétně neznám, možná to je a možná není povedená implementace ORM. Ale připadá mi srandovní tento přístup typu "To je moc velké a složité a náročné na přemýšlení, vždyť to nemůže být tak těžké. Raději to napíšu znovu a lépe". Těch zmiňovaných 333 souborů v Doctrine asi k něčemu je. To, že v nějakém konkrétním jednoduchém případě vítězí jednodušší řešení je samozřejmě možné. Ale otázka je, jestli to řešení vydrží, i když se projekt rozroste, zkomplikuje, bude potřeba větší úpravy atd. Nezjistíme náhodou, že pořád dokola překopáváme tabulky v databázi a že při každé takové změně musíme přepisovat kusy svého systému? Že by bylo dobré mít schéma někde explicitně sdílené pro celou aplikaci? Nebude problém při přechodu na jinou databázi, která teď ještě neexistuje? Co když už ani nebude relační? Neříkám, že zrovna Doctrine tohle všechno řeší. Ale řeší toho asi mnohem víc.

Tenhle scénář se ostatně opakuje pořád dokola:

- většina programátorů v PHP má za sebou alespoň jeden pokus o napsání vlastního frameworku nebo CMS

- téměř každý začínající tvůrce webů se někdy pokusí o svůj vlastní šablonovací systém

- Java je moloch, pojďme vymyslet něco jednoduššího

- XML je zbytečně složité, já to vymyslím lépe

- ORM je zbytečně složité, já to vymyslím lépe

V čem je problém? Vyřešíte pomocí svého nástroje svůj jednoduchý problém a hned jásáte: "Moje knihovna je desetkrát menší a dělá totéž totéž". Přijdou další projekty a zjistíte, že tohle chybí, tamto chybí, v horším případě, že tento přístup vám komplikuje práci. Inu co, doplníme, přepíšeme. Po letech zjistíte, že jste naprogramovali už existující řešení:

- Naše šablony by potřebovaly být ještě obecnější, ještě tuto funkci, ještě tamtu ... jejda, to už je skoro XSLT

- Do PHP na několikátý pokus konečně přidáme použitelnou podporu tříd, objektů, rozhraní, type hinty a už i namespaces a za chvíli budeme mít skoro Javu

- JSON prý bude mít schémata, namespaces ... nezačíná to něco připomínat?

- ... problematiku ORM si doplňte sami :-)

Pokud jsem zmínil něčí nenáviděnou nebo oblíbenou technologii ve špatném světle, tak se nezlobte. Technologie nejsou od toho, aby se milovaly nebo nenáviděly, ale jen od toho, aby se pochopily a používaly.

"Po letech zjistíte, že jste naprogramovali už existující řešení"
Jen s více chybami, určitou zmateností vývoje a z toho pramenící zátěží zpětné kompatibility nebo přepisování při každé příležitosti.
A v případě PHP bych si rýpnul, že při srovnání s Javou jsou paměťové nároky taky lineární: rozdíl je jen v tom, že u Javy je velká konstanta a malý koeficient lineárního členu, zatímco u PHP to je naopak :P

Škoda, že mi tu nějak zmizelo tlačítko plus. Nějak jsem si moc nezvykl hodnotit, ale občas to udělám a zrovna teď bych chtěl.

Ještě dodám trochu méně skeptický pohled k technologiím:
* Existuje tu proud jednoduchosti a komplexnosti.
* Oba proudy k sobě navzájem směřují. Komplexní technologie dostávají určité zkratky a zjednodušení a jednoduché technologie nabývají komplexnosti.
* Po určité době vývoje bude zařazení mezi jednoduché nebo komplexní jen otázkou historie.
* Jako konzervativnější proud zjednodušování komplexních věcí bych viděl Javu 7 a 8, Lombok a Spring Roo. (Poslední jmenovaný jsem viděl spíše narychlo.)
* Jako pokrokovější proud bych viděl například Scalu a knihovny/frameworky okolo ní.
(Není tu striktní rozdělení mezi konzervativnější a pokrokovější proud - můžete to vidět mírně jinak.)

Ad „Škoda, že mi tu nějak zmizelo tlačítko plus.“

Ono nezmizelo, jen není vidět. Stačí najet na to správné místo a kliknout (pozná se to podle bubliny).

Asi to spoustu lidí překvapí, ale já mezi tuto většinu nepatřím - nikdy jsem si nenapsal vlastní framework, CMS, šablonovací systém ani ORM.

Vytvořil jsem Adminer, o kterém by někdo mohl říct, že se pokouší znovu vynalézt phpMyAdmin, ale schválně si zkuste tyto dva nástroje chvíli používat a potom srovnat. phpMyAdmin se podle mě dostal do slepé uličky a stalo se z něj nepoužitelné monstrum, o čemž svědčí třeba i to, že vlastnosti přidané do MySQL před několika lety phpMyAdmin stále nepodporuje. Někdy je prostě snadnější všechno zahodit a začít s rozmyslem znovu. Pokud někdo nesouhlasí, tak může zkusit phpMyAdmin předělat tak, aby podporoval i jiné databázové systémy. Admineru se to podařilo.

A teď zpátky k Doctrine - nejsem velký fanda ORM, tento přístup řešení problémů mi příliš nevyhovuje. Navíc implementaci této techniky v Doctrine považuji za zoufalou. A to je přesně okamžik pro zamyšlení nad tím, jestli by problém nešel vyřešit i nějak jinak, a případně toto řešení vytvořit (pokud ještě neexistuje). NotORM nabízí ve srovnání s Doctrine koncepčně zcela odlišný přístup a rozhodně se nesnaží o to stát se lepší Doctrine. Lepším nástrojem pro řešení stejného problému ale rozhodně ano.

100% súhlas

súhlas

Na úvod řeknu, že nejsem nějaký zkušený Doctrinista, ale už jsem viděl (z diskusí a článků) prosakující abstrakci:
* U IN prý při předání prázdného pole dojde k chybě. (Prosakují zde vlastnosti SQL, přičemž by nebyl velký problém tuto podmínku přepsat na něco jako false.)
* V případě porušení nějakého omezení (např. duplikace nějaké hodnoty) prý dojde k PDOException.

Na jednu stranu, nemyslím, že se s tím NotORM vypořádá lépe, na druhou stranu, od NotORM bych to neočekával. Od ORM ano. Do nižší vrstvy bych měl vidět obecně nanejvýše v konstruktoru a při nějaké chybě nižší vrstvy, která by běžně neměla nastat (vypadlo spojení s DB). Ne při chybách, které nastat běžně mohou (duplicate constraint violation). Z tohoto pohledu NotORM není vrstva, ale jen curklátko.

Stručně: Řekl bych, že NotORM lépe plní svoji úlohu, ale je to z velké části tím, že není tak abbiciózní.

Pokud Doctrine někde vyhazuje PDOException, tak je to podle mě zásadní problém, protože zvenku mě vůbec nemusí zajímat, že Doctrine PDO používá.

Naopak NotORM se k závislosti na PDO přiznává (v konstruktoru přijímá přímo objekt PDO) a chyby zcela záměrně neeskaluje - ty respektují chybovou úroveň nastavenou v PDO.

Co se vypořádání s chybami týče, tak konkrétně prázdné pole NotORM samozřejmě nijak nerozhodí - překládá se na IN (NULL).

Co se ambicióznosti týče - víš o nějakém problému, který se v Doctrine řeší pohodlně a v NotORM nejde vyřešit vůbec nebo se řeší krkolomně?

"NotORM se k závislosti na PDO přiznává (v konstruktoru přijímá přímo objekt PDO)"
Obecně to bývá u vrstvy snad jediné místo, kde je možné přiznat svoje závislosti. I ORM se může přiznávat k těmto závislostem v konstrktoru, ale ne při používání. Pak stačí vyměnit implementaci (např. Dibi místo PDO - možná ne nejšťastnější příklad, ale první, co mě napadlo) a zbytek funguje vesele dál.

"víš o nějakém problému, který se v Doctrine řeší pohodlně a v NotORM nejde vyřešit vůbec nebo se řeší krkolomně?"
Určitě se toho najde více, ale u Doctrine je například možné zapouzdřit celkem dobře způsob ukládání dat.

Můžeš prosím podrobněji rozebrat, co se skrývá pod pojmem "zapouzdřit způsob ukládání dat"?

Já jsem mluvil o problémech, které je potřeba řešit. Mapování řádků DB na instance různých tříd může být způsobem řešení těchto problémů, ale není to samotným problémem.

Zkus prosím sestavit zadání nějakého problému z pohledu zadavatele.

Ak tomu dobre rozumiem, NotORM vzniklo preto, lebo autor nesuhlasi s filozofiou ORM ako takeho (http://www.notorm.com/#why). Preto dost dobre nerozumiem, preco nakoniec svoj produkt ide vobec porovnavat s nejakym inym ORM. Kazdy z nastrojov je IMHO urceny pre inu cielovu skupinu aplikacii.

Tento článek je primárně o Doctrine (původně v titulku ani NotORM nebylo uvedené). Nejde o porovnání Doctrine s NotORM, ale o kritiku Doctrine samého o sobě. Stejný problém je vyřešen i v NotORM z toho důvodu, aby bylo vidět, že je řešitelný mnohem snadněji - tedy že nejde o "tak složitý problém, že se sice v Doctrine řeší špatně, ale lépe to prostě nejde".

Co se cílové skupiny aplikací týče - já neznám aplikaci, ve které bych se chtěl bez NotORM obejít a naopak mě nenapadá aplikace, na kterou by se hodilo Doctrine.

Tj je možnost, že by vývojář definoval schéma za pomocí doctrine a využíval jeho schopnosti kde se to hodí a části, které jsou špatně řešitelné využil NotORM? To by mohlo plnit objekty definované přes doctrine schéma.

Nebo nebude to takhle v Nette?

V Javě se to občas stane, že je třeba trochu ORM pomoci a nevidím v tom velký problém. Teda hlavně v Javě je pro tohle podpora.

Mimochodem, ti z vás které už ta řehole okolo PHP nebaví, zkuste se podívat na Play Framework. Možná zjistíte, že vývoj v Javě není taková pruda jak se říká.

Problém je v tom, že mě se v Doctrine řeší špatně prakticky vše. Takže by zůstalo jen definování schématu, ale i to se mi pohodlněji dělá v Admineru.

Nette zvolilo stejný přístup jako NotORM. Model (tedy seznam operací aplikace) je vhodné u NotORM i v Nette definovat mimo entity (což se doporučuje v Doctrine). O tom bude třetí část seriálu.

"zkuste se podívat na Play Framework. Možná zjistíte, že vývoj v Javě není taková pruda jak se říká."
Nebo objevíte i jazyk Scala. Taková Java s jednodušší syntaxí. V komunitě Play! celkem populární jazyk.

BTW: napsal jsi v tom Play už něco většího? Je to někde k vidění? Když jsem na tenhle framework koukal, úvodní video je úžasné, všechno vypadá skvěle, ale pořád mi to přišlo takové spíš na hraní… dělat v tom něco pořádného jsem zatím neměl odvahu.

Zatím ne. Zvažovali jsme to pro jeden projekt, ale dost možná nakonec pro tuto část použijeme Node.js a já se budu věnovat jiným částem.

U Scaly je situace trošku jiná - je v tom napsán nějaký systém pro Twitter.

http://www.artima.com/scalazine/articles/twitter_on_scala.html
http://www.slideshare.net/al3x/why-scala-presentation

Ja v tom delam uz vsechny sve projekty. Zkusil jsem to a fakt nemam duvod hledat jiny. Ta efektivita je neuveritelna. Nevim proc ti to prijde na hrani.

Je škoda toho pořadí a volby jednotlivých bodů, zbytečně jdou "chronologicky", takže každý řeší těch 333 souborů, což je skutečně úplná ptákovina, a k důležitým tématům, jako je efektivita práce s API a především efektivita práce Doctrine s databází, se řada čtenářů asi ani nedostane. Asi by bylo přínosnější rozepsat body 11, 12, 13 do samostatného článku, něco jako byl tento http://zdrojak.root.cz/clanky/phpmyadmin-vs-adminer/

Řada lidí o použití Doctrine uvažuje. Takovýto seriál jim může s rozhodováním pomoci.

Žádný eager-load v Doctrine 2 není. Až bude (je plánován do verze 2.1), tak se jedna připomínka stane bezpředmětná, ale osobně bych raději nejdřív počkal na to, jak bude implementace vypadat.

Odpovědi Beberleiho zveřejněné jsou. Paradoxně na mém blogu, i když by se o to podle mě měli přičinit spíš příznivci Doctrine. Ale ony toho stejně moc neřeší, z těch nejzásadnějších věcí: Eager-load snad někdy bude, bez DQL se nedá obejít a složitost jakýchkoliv změn je nevyhnutelná.

výraz "mít v úctě cizí práci" považuji za naprosto pomýlený. zavádí k tomu, že by snad člověk měl mít v úctě práci špatnou nebo práci zbytečnou. to je nesmysl. na práci samotné nic úctyhodného není. snaha zaslouží uznání, VÝSLEDEK práce, pokud je dobrý, zaslouží úctu. Jakubův článek je právě o hodnocení tohoto výsledku z jiného pohledu. je celkem věcný a nevyznívá nijak urážlivě nebo hanlivě pro Doctrinu ani její autory. i když jsou některé Jakubovy argumenty malicherné (třeba "333"), někomu mohou přijít důležité, nebo hohou být třeba pomyslnou poslední kapkou při rozhodování jakou technologii nasadit

odborný magazín by si neměl dovolit zveřejňovat pouze názory jedné strany. jsem velmi rád za výborné články Honzy Tichého o Doctrině (přesto že mě některé z nich doslova vyděsily), ale krom kladů je třeba znát i zápory

Neznam dobre ani Doctrine2 ani NotORM, u obou jsem videl jen par slajdu a examplu. NotORM pracuje pouze s databazemi ze? U Doctrine2 jsou to take pouze DB?

Mozna se pletu, tak me pripadne opravte. Pokud ano, tak co jsem povazoval za ORM, jim asi neni. Ale ORM snad neni jen o DB ne?
Ale o modelu, ktery zustava v aplikaci stejny. Stale stejna prace s modelem, nehlede na to z ceho se tahaj data. At je to DB (oracle, postgre, m$), xml nebo nejakej druh cache. Stale pracuji s modelem stejne, jen dle potreby premapuju zdroj.

A jen tak mimochodem jak je to se skalovatelnosti?

Diky za pripadnou odpoved ;)

ORM znamená objektově-relační mapování – jde o propojení objektového světa právě se světem relačních databází. Pokud bys chtěl mapování objektů na např. XML, tak k tomu jsou jiné nástroje (v javě třeba JAXB). Pokud by to mělo být obecné rozhraní nad jakýmkoli úložištěm (databáze, soubory, RAM, síť…), tak na to je takový návrhový vzor ;-) (ORM samo o sobě na to nestačí)

Jo ahaa, no tak to uz mi pozapadaly kosticky do sebe, diky. Nejak jsem v ty moji prazdny mozkovne smichal ORM s DDD.

Existuje tak velky projekt aby na nem melo smysl pouzit doctrine?

Ano. V podstatě jakmile vývojář zjistí, že bez JOINu v SQL dotazech to už asi nepůjde, měl by současně zvážit, jestli by nebylo lepší použít něco jako ORM. I když třeba ne nutně zrovna Doctrine.

napriklad Doctrine pro mne neni natolik pruhledneabych si mohl byt jist tim ze kdyz se ma vytvorit dotaz s inner bude tam a kdyz s left tak tam taky bude. pred lety sem narazil na cakephp, zalibyl se mi z nej model, lec sem narazil na nejaka ta omezeni a pak na adodb a to me odradilo a prinutilo napsat si orm nad vlastnim frameworkem, tedy jeho vrstvou pro praci s databazi. uprednostnil sem pred vseobjimajicim resenim, vlastni reseni na 1500 radkach v jednom souboru, coz uznavam je presne proti vetsine pravidel pro oop, nicmene to funguje, podle mych predstav, a jsem spokojen. samozrejme neresi vse, ale jen to co potrebuji. na frontu ovsem toto nepouzivam, na frontu pouzivam trochu jine dva pristupy, jeden je primi pristup pres dabatazovou vrstvu k datum, tj napisu si presne select na to co chci, a druhej je ze odvodim tridu od vrstvy pohledu, predvyplnim jake chci sloupce, jake podminky, jaka spojeni, a nasledne z pohledu odvozuju dalsi specifictejsi pohledy, na pohled pak vesim filtr, strankovani, razeni, takove ty bezne veci co front potrebuje. toto reseni se mi zatim osvedcilo, mam pocit z toho ze administracni cast je snadno rozsiritelna, a front je vykonny.

S ORM byste se právě neměl starat, jestli tam bude inner nebo left, ale jestli dostanete data, která chcete. Jak si to framework s DB serverem vyřeší už je celkem jeho věc. Když je to chytrý framework, tak může dotazy i optimalizovat podle použitého DB serveru.

Coz o to, pouzivani ORM me celkem laka, definovat celou databazi pres xml a nasledne definovat pohledy, nebo si je dynamicky generovat podle pozadavků, ale kdyz tak koukam na doctrine, byl bych radsi kdyby to bylo primo specializovane na mysql, nemelo to v sobe nic navic, bylo to minimalizovane, aby se to nechalo pouzit v jakemkoliv projektu jednim includem, spustilo se to zapsanim jednoho radku a nasledne se to uz jen pouzivalo.

Málokdo už dnes pochybuje o tom, že má cenu použít nějaký webový framewrok a to i pro velmi malé projekty. Díky vytrvalé evangelizaci mimo jiné i ze strany Zdrojáku, skoro každý chápe, že to přinese minimálně větší bezpečnost, produktivitu a rozšiřitelnost do budoucna.

ORM představuje něco podobného v oblasti přístupu k datům. Cílem je nahradit nízkoúrovňový "ruční" přístup, který si člověk musí kompletně ohlídat sám, něčím obecnějším, co se snadněji kontroluje a udržuje. Rozdíl je jen v tom, že Doctrine nemá žádného průbojného "věrozvěsta", který by tohle omílal při každé příležitosti :-)

Musím s autorem souhlasit. Dělám s Doctrine 2 roky a je to hrůza... ale zase bych ORM tak nezatracoval, třeba když to někdy někdo dobře naimplementuje, tak to třeba bude i použitelné...

Děláš roky s Doctrine 2 (což je nemožné) nebo 2 roky s Doctrine 1, což je úplně jiný projekt než ten, o kterém je článek?

Doctrine je docela moloch, chvilku sem si s nim hrál a pocity jsou takový, že to funguje, dá se s tim pracovat, ale je to moc napuchlý a neefektivní (nejspíš sem se s tim jen nenaučil pořádně pracovat).

notORM sem hned taky vyzkoušel (doteď jsem neznal) a nechápu proč ste se vůbec zabýval srovnánim s Doctrine - úplně jinde, úplně o něčem jinym a prakticky žádný zefektivnění PRÁCE nepřináší.

používal sem zend (právě s doctrine) a nějak sem přešel na kohanu, protože se mi zalíbil její minimalistickej přístup, hezká dokumentace a hlavně to, že všechno mi fungovalo hned na poprvý (u zendu bylo docela dost WTF momentů). Vyzkoušel sem ORM v kohaně a prostě stačí - "gets the job DONE"

dělam "menší a středně velký projekty"

Zdravim,

ad 2) Ano, cast Doctrine pouziva Symphony, ale jen pro pristup z terminalu - pro update a dalsi praci s db. Tato vrstva je jeji interni a pri beznem HTTP REQUESTU SE tudiz NEPOUZIVA ;-)

ad 3) Proxy jsou velice dulezite, pro optimalizaci loadu collections. Proto je dobre si v terminalu vygenerovat vsechny proxy rucne po kazdem update databaze (pri zmene vazby).

ad 4) Preklep anotace resi validace a pripadny sql dump v terminalu - zkuseny programator, vi, ze bud ma davat pozor, anebo kopirovat, coz je defacto nejjistejsi ;-)

ad 5) s timto jsem se nesetkal

ad 7) ano nikde nas nemusi zajimat pri vyvoji aplikace (coz je dobre), ale v praxi, pokud clovek pouziva promenne ze slozenych nazvu s "first higher char", pak vygenerovani nazvu coumns/tables case sensitive muze na linuxovych serverech delat neplechu a je spravne, ze clovek si muze nazvy tabulek a bunek databaze navrhnout sam. Logicky tak oddeli db model (api) a strukturu databaze.

A dal me to nebavi cist uz....

Jinak jsem cetl taky nejakou narazku na vykon - ano, doctrine asi nepouziju na nejaky extra vytizeny eshop, ale pro bezne weby neni rezie vubec znat a kdo chce, tak si nacachuje, co je treba. V doctrine jsme psali i velke projekty a prakticky neni videt rozdil mezi Doctrine a nejakym "not orm db layerem" :-)

Rekl bych, ze je to jen uboha snaha zviditelnit svoji databazovou knihovnu. Preci jen autori doctrine nejsou zadna becka narozdil od toho, kdo si o doctrine neumi zjistit nebo vyzkouset klicove veci :-)