Nette\Database zkušenosti

Patrik Votoček

Nette\Database je tu už nějaký čas. A tak se ptám lidí kteří ji ozkoušely nebo ji používají. Na zkušenosti, dojmy, zajímavosti atd. Takže sem s tím.

JakubJarabica

Ráta sa aj samotné NotORM? To využívam kvôli možnosti multijazyčnosti: http://php.vrana.cz/…o-notorm.php, ale stále mi chýbaju featury z dibi ako napr. fetchPairs, fetchAssoc. V bakalárke používam Doctrine 2 ale to je príliš kanón, najmä na projekty, ktoré nie sú rozsiahle to je dosť na škodu.

A čisto súkromný názor: škoda, že Nette\Database nie je NotORM nad dibi – dibi s možnosťou „lazy joining“ prislúchajúcich tabuliek v šablóne($auction->product[‚title‘] – s NotORM to podľa aktuálneho jazyka aplikácie vytiahne príslušný lokalizovaný title).

srigi

Ja pouzivam tiez iba ciste NotORM s hentou vecou, co som napisal do kucharky. Nette\Database mi pripada tak trochu ako chudobnejsi pribuzdny NotORM:

nema to (zatial) moznost vlastnych mennych konvencii,
je ukecanejsia

$connection->table('foo');
// vs.
$connection->foo();

nejake veci tam aj nefunguju

$connection->table('foo')->order('bar.name DESC'); // foo has many bars (alebo naopak, kto si to ma pamatat)
// toto uz ide
$connection->table('foo')->order('bar.name DESC '); // WTF?

V com ma Nette\Database navrch je profiler. V debug paneliku je viac info ako v tom mojom k NotORM. Moj dojem z Nette\Database je ale skor negativny (no disrespect). Osobne budem uprednostnovat NotORM.

Editoval srigi (11. 3. 2011 8:34)

Honza Marek

Ta ukecanost mi nepřijde vyloženě na škodu. Když jsem viděl Jakuba NotORM předvádět, tak jsem se ve změti těch ArrayAccessů, __getů a __callů trochu ztrácel.

Oggy

Také používám čiště NOTORM a po prvotních tápáních ohledně syntaxe jsem velice spokojen. Jakub na dotazy buďto ohledně nějakých neobvyklejších složení dotazů (přece jen potřeba trochu změnit přemýšlení narozdíl od psaní SQL dotazů) tady na fóru nebo na webu odpovídá rychle.

ale stále mi chýbaju featury z dibi ako napr. fetchPairs, fetchAssoc.

<?php
	static function fetchPairs($table, $column) {
		return self::$notORM->$table()->fetchPairs("id", $column);
	}
?>

Vyki

S Nette\Database nyní experimentuji vrámci nového projektu, takže zatím jsem v začátcích. Když napíšu pár svých zkušenností:

v base modelu jsem si doplnil podporu magických volání findOneByParam, findByParam, findAll (něco jako napsal v kuchařce srigi pro čistě NOTORM, ale implementace pro Nette\Database se mi podařila výrazně zjednodušit, půjčil jsem si pouze ten regex, tímto za něj děkuji)
oproti doctrine mi chybí možnost getterů a setterů bývají v entitě. V provizorním provozu se mi totiž liší názvy sloupců v provizorní a ostré tabulce a v entitě bych to mohl jednoduše ošetřit aniž bych potom musel sáhnout na názvy proměnných do aplikace až provizorní provoz skončí. Názvy ani jedné z těch tabulek měnit totiž nesmím (ani nemůžu). Pokud by někdo věděl jak to vyřešit budu rád.
nejsilnější zbraní je bezesporu TableSelection a způsob jakým umí pracovat a s asociacemi, je to silně návykové, pracuje se s tím opravdu dobře
další poznatky přidám v průběhu vývoje

Editoval Vyki (11. 3. 2011 23:52)

vrana

Vyki napsal(a):

oproti doctrine mi chybí možnost getterů a setterů bývají v entitě. V provizorním provozu se mi totiž liší názvy sloupců v provizorní a ostré tabulce a v entitě bych to mohl jednoduše ošetřit aniž bych potom musel sáhnout na názvy proměnných do aplikace až provizorní provoz skončí. Názvy ani jedné z těch tabulek měnit totiž nesmím (ani nemůžu). Pokud by někdo věděl jak to vyřešit budu rád.

V NotORM by stačilo podědit NotORM_Row, ale v Nette\Database to nejde.

Honza Marek

vrana napsal(a):

V NotORM by stačilo podědit NotORM_Row, ale v Nette\Database to nejde.

Jde v NotORM nastavit, aby výsledky vydolované z nějaké tabulky byly vraceny vždy v instanci nějaké třídy? Třeba z tabulky article aby lezl nějaký MyApp\Model\Article a z users MyApp\Model\User?

vrana

Nejde to a je to v rozporu s myšlenkou NotORM. Tímhle by se z toho totiž udělalo ORM. Navíc co by ten objekt asi tak mohl dělat, když všechny vlastnosti a metody už jsou zabrané pro práci se vztahy?

Mnohem lepší návrh mi přijde, když jsou tyhle dvě věci rozdělené – NotORM_Row schopné pracovat s daty a jejich vztahy a MyApp\Model\Article a spol. schopné pracovat s jejich operacemi (např. vložení článku včetně všech jeho značek). Tyto dvě věci se spojí velmi snadno pomocí new MyApp\Model\Article($notORM_Row) – o to by se měl starat model.

Honza Marek

vrana napsal(a):

Tímhle by se z toho totiž udělalo ORM.

Přesně tak :)

Navíc co by ten objekt asi tak mohl dělat, když všechny vlastnosti a metody už jsou zabrané pro práci se vztahy?

Pokud se nepletu, tak v Nette\Database tomu tak není. Tam by to tedy šlo.

vrana

A co by mělo vracet třeba $book->book_tag()? book_tag je pouze vazební tabulka a entita pro ni tedy nejspíš existovat nebude.

Vyki

Tak přemýšlím jestli Nette\Database má vůbec cenu. Zkoušel jsem s tím teď pár dní pracovat, ale přejdu k NOTORM, které je ještě stále (a pravděpodobně i bude) o hodně vychytanější.