doctrine 2 – sandbox a jak dál

Můžeš se inspirovat HosipLanovým DAO – http://www.aceblog.cz/…-dava-smysl/. Nebo prostě zkusit v presenteru něco jako:

public function renderDefault()
{
	// způsob přístupu k EM si upravíš podle toho, jaký sandbox použiješ...
	$this->template->data = $this->context->doctrine->entityManager->getRepository('User')->findBy(array('active' => TRUE));

	// nebo - DQL - vykopírováno z jednoho projektu
	$query = $this->context->doctrine->entityManager->createQuery('SELECT e, r, a FROM AvalonProject\Entities\FairyTail\Episode e
		LEFT JOIN e.subtitles r LEFT JOIN e.arc a ORDER BY e.isOva ASC, e.aired DESC');
	$this->template->episodes = $query->getResult();
}

<ul n:inner-foreach="$data as $user">
	<li>{$user->name}</li>
</ul>

Entity si ukládej kam chceš, hlavně je Doctrine musí najít. Já je mám třeba v %appDir%/entities…

Dokumentaci samotnou jsem zatím jen prolítnul, pročítal jsem seriál na zdrojáku.cz.
Osobně mi samotná dokumentace zatím moc nedá – je tam jen spousta nových pojmů, které se mi jen pletou dohromady.
Až když si to sám vyzkoušim, začne se to v hlavě třídit a dokážu si pod slovem entity mapper a spoustou dalších pojmů představit něco konkrétního. Pak je čas pročíst dokumentaci pořádně :)

Něco mi sandbox už dělá…brzy se zase vrátím s nějakým „obrovským“ problémem.

Podobný otázky si se snažim taky zodpovědět – jen zatim nemam konkrétní představu jak to dělat lze a jak bych to mohl dělat já.
Resp. zatím jsem se definitivně nerozhodl doctrine použít – mám toho už dost napsanýho pomocí dibi ale pořád to neni tak úplně ono.

awsickness napsal(a):
dalsi pohled je mit entitu a ta by mela umet sama nad sebou pracovat ?

To potom není ORM, ale Active Record ($entity->save() etc.), kterej IMHO porušuje SRP a pokud nepoužíváš jazyk, kterej se na tohle hodí (ruby, smalltalk), tak se lehce dostaneš do problémů (třeba při testování).

@HosipLan: obě diskuse už jsem v minulosti četl…a teď zase. Výsledek je, že z toho mam akorát depku :)
Mj. jsi tam kritizoval mít různý model pro administraci a různý pro frontend, což používám.
V modelu pro frontend jsou klasické metody jako getOne, getAll apod., které vytahují téměř připravená data z DB view.
V administraci mám basemodel s metodami insert, update, delete apod. které automaticky podle struktury tabulky generují sql dotazy. Zjišťuji tam struktury tabulek v DB a případně rozložím data z formuláře do více tabulek (typicky hlavička a jazykově závislá data) apod.

Hlavní je, že se v té admin části občas začínám ztrácet, často to musím stejně přepsat pro konkrétní model a občas je to WTF.
Tohle je něco, kde si slibuju od doctrine výrazné usnadnění díky mapování a propojení entit. Naprostá většina dat se skládá z tabulky pro hlavičku a z tabulky pro jazykově závislé texty, kde může být k jedné hlavičce více záznamů pro různé jazyky.

Otázka 1:
Pokud chápu asociace, tak samotná entita Zbozi bude napojená na další entity podobně jako jsou spojené přes foreign keys v DB? Výsledkem tedy bude hromada navzájem propojených entit (v kterých se po čase člověk taky ztratí).

Chci se zeptat na tvoření entit – konkrétně pro zboží. Informace o zboží jsou rozprsklé asi ve 20ti tabulkách – základní informace, parametry, varianty, obrázky, přílohy, historie cen apod., většina vícejazyčně.

Otázka 2:
Lze Zbozi (tedy dvě základní tabulky – hlavičku a texty) definovat jako jednu entitu nebo musím jako dvě Zbozi a ZboziText ? Pracovat budu vždy se zbožím jako jedním objektem a při uložení budu chtít aby se to do těchto tabulek „samo“ rozdělilo…na jaké by to mělo být úrovni? Repository nebo ještě výš?

Díky.

awsickness napsal(a):

mit entitu a ta by mela umet sama nad sebou pracovat ?

To je případ Doctine ORM 1 kdy to bylo postavené jako Active Record

Doctrine ORM 2 je naopak postaveno na Data Mapperu.

Snažit se Doctrine ORM 2 ohýbat na Active Record je tak trochu drbání se levou nohou za pravým uchem.

mkoubik napsal(a):

To potom není ORM, ale Active Record …

bullshit… AR je taky ORM taky to mapuje objekty s relacema… :-)

Filip111 napsal(a):

… Mj. jsi tam kritizoval mít různý model pro administraci a různý pro frontend, což používám.

Pokud je tím myšlen model jako celek tak je to špatně. Pokud je tím myšlena určitá část (manipulace s datama) tak tam to smysl dává.

Sám ve starších projektech používám dělení Repository vs. Service viz několik článků:

• http://www.vrtak-cz.net/…a-doctrine-1
• http://www.vrtak-cz.net/…a-doctrine-2

Otázka 1: … Otázka 2: …

Na obě otázky se dá odpovědět zároveň. V tomhle je právě síla ORM a nejtěžší věc na naučení. Musíš přestat nad daty uvažovat jako o tabulkách v DB. Musíš o nich uvažovat jako o entitách.

Entity ti totiž umožní třeba tohle: http://www.doctrine-project.org/…mapping.html :-)

Well, Kdyby není ready na produkci, takže je to zatím spíše na hraní ;)

Co se týče Doctrine 2, tak ta se zase tak moc nemění a docela si i drží zpětnou kompatibilitu a mají dobrý changelog.

Ohledně více frameworků, já mám na projektu teď 4 frameworky a asi 7 dalších knihoven :) Hrůzné, že? Ani ne, protože je nikdy nepoužívám v jeden moment všechny zároveň. Vždycky jen co se týká jedné části aplikace.

1. U minimálně dvou sloupců ti chybí komentáře ve stylu phpDoc – tedy /** (ty dvě hvězdičky tam prostě musí být)
2. Správnost definic entit si můžeš ověřit přes CLI interface Doctrine 2.

ad 1) aha, hvězdičky..po opravě to vygeneruje správný sql dump

ad 2) v dokumentaci cli jsem našel akorát generate-entity ale nic co by entitu jen zkontrolovalo
Nicméně u této otázky mi šlo spíš o kontrolu mojí úvahy – použití joinu a zvolení vztahu ManyToOne

@HosipLan:
ad 3) Nenašel bys nějaký odkaz, který by mě nasměroval – zkoušel jsem něco googlit, ale nenašel jsem nic relevantního.
Je to pro mě stěžejní věc bez které se dál nehnu – asi 80% objektů, které mám v databázi jsou jazykově závislé – mají dělený obsah do dvou tabulek. Dokud tohle nebudu umět v Doctrine efektivně vyřešit, můžu na ní (na ně?) zapomenout.

Díky.