Bezbolestná integrace Doctrine 2 ORM do Nette – Kdyby/Doctrine

Měl bych dotaz. Když se vytvoří služba takto:

services:
    articles: App\Articles(@doctrine.dao(App\Article))

Tak se ty nativní DQL skládají přímo v presenteru/komponentě kde se ta služba používá? V současné chvíli totiž používám jinou extension pro doctrine a mám to rozdělené na Entitu – Fasádu – Repozitář a jako službu si předám fasádu která podědí základní metody repozitáře a DQL které potřebuju navíc si pak poskládám v repozitáři.

Jak to tedy funguje s tvým rozšířením?

EDIT:
Takže jsem to pochopil trošku špatně a našel tento článek: http://www.frosty22.cz/…ccess-object

Pokud to tedy již chápu dobře, to co já mám teď jako fasádu je u kdyby model a repozitář zůstává prakticky bezezměn, je tak?

Editoval akadlec (18. 9. 2013 9:17)

Ok chápu. A to co je uvedeno v tom článku je korektní příklad?

Jo ten konstruktor se mě tam taky nelibí a jako ilustrace to možná mate více než je zdrávo. Ad dao, je tedy lepší si nedělat ty vlastní classy dao pro jednotlivé modely a využívat tak jen dao z kdyby?

Pěkné rozšíření, ale dneska by dalo zabrat, nevím, jeslti je to moje neznalost, či kde je problém. Zkrátka mám entitu Game, ta má v sobě kolekci $pictures (OneToMany). V kódu jsem potom k této kolekci přistoupil, upravil mj. jeden atribut v ní a uložil. Pseudokód

$game = $this->gameDao->find(1);
$game->getPictures()->get([0])->setPath($newPath);
$this->gameDao->save($game);

no a po uložení se v databázi ona změna neprovedla. Ŕíkal jsem si ok, tak nebero to prvky v kolekci, zavolám $this->gameDao->flush(); nicméně ani to změnu neprovedlo. Musím si exciplitně vytáhnout entitymanager a přes něj zavolat flush() a pak změna proběhne. Chápu to tedy tak, že pokud volám přes dao objekt metodu save/flush, tak se ty změny provádí jenom v rámci entity, ke které je DAO vázáno. Chápu to dobře? Je to opravdu žádoucí, nebylo by lepší pokud by alespoň flush u dao flushnul všechny změny a nemusel se tahat explicitně EntityManager?

Díky, jak jsem tak nad tím přemýšlel, tak mi došlo, že to přeci jen dává asi spíše smysl, jak ot je teď implementováné, že by se zkrázka dao mělo starat opravdu jen o ty entity, které jsou jeho, jen to občas může holt zmást:-)

Ten kód byl spíše pseudokód + hodně zkrácený, abych naznačil, co myslím.

EntityManager si tady předám, ať mi to proběhne hezky v jedné transakci. Což je právě taky podle mě trochu problém toho řešení současného, že to neflushuje všechny změny, zkrátka když pracuji s více DAO a entitami v jedné mětodě, tak většinou chci, aby to proběhlo v jedné transakci, a tak nemohu využít save(), ale musím nakoenc sáhnout pro entitymanager. Ale sám nevím, co je lepší:)

Nenačítat vendor složku RobotLoaderem. Použij autoloader generovaný Composerem (vendor/autoload.php).

Zdravím!
Rád bych použil kdyby/doctrine v kombinaci s o5/Grido, který jako zdroj přejímá Doctrine/Querybuilder.
Mám tedy entitu User, která dědí od IdentifiedEntity, s vlastnostmi username, email, password atd.

S kódem dole dostávám RuntimeException Not all identifier properties can be found in the ResultSetMapping: id. Id je přitom děděné z IdentifiedEntity a v selectu je taky uvedeno.

$users = $this->em->getDao(User::getClassName());
$u = $users->createQueryBuilder()
            ->select('u.id')
            ->from('AdminModule\User', 'u');

Když na tom kódu spustím getQuery() a teprve ten potom execute()-uju, vrací správný výsledek. Pokud byste někdo měl nějaký nápad, sem s ním.

Přikládám ještě část IdentifiedEntity, kde je vlastně jen změněno namapování vlastnosti id na sloupec guid v db.

abstract class IdentifiedEntity extends BaseEntity
{

	/**
	 * @var string
	 * @ORM\Id
	 * @ORM\Column(type="string", name="guid")
	 * @ORM\GeneratedValue
	 */
	protected $id;
	...

Díky, pomohlo.

1. Zapni nějaké cachování (apc/redis/memcache), bez memory cache se doctrine naprosto reálně používat nedá (ani čistá).
2. Kdyby žádný overhead nepřidává, pouze v development módu hodně kontroluje, jestli jsi něco nezměnil, aby se ti aplikace chovala dle očekávání. Zapni aplikaci v produkčním módu a pak to změř.

Moje aplikace se načítá 2–8 vteřin v development módu a 200–600ms v produkčním módu na serveru.

@Stic: Tohle nastavení za tebe řeší Kdyby. Tyhle čtyři nastavení si můžeš změnit na jednu z podporovaných hodnot

Trošku jsem vylepšil práci s memcachí, protože jsem si všiml, že ten výchozí driver má setter a blbě by se konfiguroval, teď (po aktualizaci Kdyby/Doctrine) by to mělo jít nějak takto

doctrine:
	metadataCache: memcache(@memcache.client)
	queryCache: memcache(@memcache.client)
	resultCache: memcache(@memcache.client)
	hydrationCache: memcache(@memcache.client)

services:
	memcache.client:
		class: Memcache()
		setup:
			- addserver(localhost, 11211)

A nebo můžeš nastavit pro celou aplikaci datovou cache na memcache a protože Kdyby/Doctrine by default používá systémovou datovou cache, bude se používat ta.

services:
	cacheStorage:
		class: Nette\Caching\Storages\MemcachedStorage()

@enumag: ne, stačí jenom zapnout storage, který nahradí ten systémový a tedy ho bude automaticky používat i Kdyby/Doctrine.

Přečti si ten můj příspěvek o memcachi znovu :)

Rozdíl je v tom, že když tu memcache narveš rovnou do doctriny a nebudeš tam nechávat mezikrok v podobě Nette\Caching\Cache bude to rychlejší (ale přijdeš o zamykání).

Zdravím,
potřeboval bych mít možnost sestavit EntityManager na základě uživatelské identity. Pokud bude uživatel nepřihlášený, použijí se pro nastavení Doctrine údaje uvedené v config.neon, pokud se ale přihlásí, chtěl bych vytáhnout Nette\Security\IIdentity a pro přihlášení do DB použít jméno a heslo právě přihlášeného uživatele.

Lze teda nějak v configu přepsat defaultní EntityManager? Pokud si teď podědím Kdyby\Doctrine\EntityManager a zaregistruju ho do services, dostávám Service 'doctrine.dao': Multiple services of type Kdyby\Doctrine\EntityManager found: doctrine.default.entityManager, manager.

@frosty22: Zkoušel jsem něco podobného, teď jsem tedy zkusil i tebou navrhovanou variantu, smazal cache, ale stejně tam zůstává defaultní EM. Čekal bych, že to na mě zařve, že neexistuje definovaná třída Muj\EntityManagerFactory, ale to se bohužel taky neděje.

@frosty22: Já ti nevím ale nemá být tohle spíš v sekci services?

@frosty: No služby se běžně předefinovávají takhle (ale možná má Kdyby/Doctrine nějaký jiný mechanismus):

services:
	doctrine.orm.defaultEntityManager: ...

Můžu se zeptat, jak to vypadá s integrací Nette formulářů a validátory? Koukal jsem, že na GitHubu je DoctrineForms, je to už použitelné nebo zatím spíše náčrt? Případně nějaký sample?

Ako by som vedel zmazat a znovu vytvorit databazu priamo v prezenteri ? (bez rucneho spustania „orm:schema-tool:drop –force“ a „orm:schema-tool:drop“ , pre selenium testy )

Editoval songoo (24. 11. 2013 21:12)

Diky moc ide to :)

Kdyby\Doctrine rozhodně nekontroluje žádné tvoje třídy, nijak to spolu absolutně nesouvisí, tohle kontroluje sám DI Container v Nette.

Ohledně té výjimky s přejenováním – vsadil bych se, že máš špatnou verzi kdyby/doctrine nainstalovanou, zkus si pořádně přečíst jak se to instaluje a udělat po správně.

@Filip Procházka instaloval som to takto, a ladenka hadze toto

"kdyby/doctrine": "@dev",
"kdyby/annotations": "@dev",
"kdyby/doctrine-cache": "@dev",
"kdyby/events": "@dev",
"kdyby/console": "@dev"

extensions:
	console: Kdyby\Console\DI\ConsoleExtension
	events: Kdyby\Events\DI\EventsExtension
	annotations: Kdyby\Annotations\DI\AnnotationsExtension
	doctrine: Kdyby\Doctrine\DI\OrmExtension

@Jiří Nápravník tu extension nemam ani v extension zapnutu, a ked vymazem ten subor, tak ako som hore spomenul, naslo si dalsi subor ktory robil problem a dalej som uz neskusal ani mazat.

@Quinix ano mam to tak, takze to mam specifikovat na konkretne adresare?

@duskohu, @enumag, @Filip Procházka: napraveno

Je to normální, ale dá se to změnit pomocí cascade persist.