Modul ve více projektech – entita (doctrine)

No s těmi entitami nevim nevim, služby dokážeš přetížit, ale entity jsou složitější. Leda přetížit celý modul a v něm ty entity.

Něco takového taky řeším. Konkrétně s uživateli. Mám modul kde se spravují uživatelé se základními daty a pak druhý modul kde se spravují kontakty jednotlivých uživatelů. A v entitě uživatele mě právě chybí atribut určující relaci uživatel-kontakty :/

Resil bych to podedenim ty entity a pridanim fieldu. Je tam ale par problemu.

Vetsinu problemu by melo vyresit targetEntityMappings, zbyva jeden problem a to je, ze bude pravdepobodne nutne z te originalni entity udelat mapped superclass, coz by slo taky pomoci loadClassMetadata listeneru. Ale nektere veci v ClassMetadataFactory jsou zavisle na tom, jestli trida je entita nebo mapped superclass. takze to mozna budes muset nejak premapovat

Díky, nastuduji a odzkouším

Nejde dynamicky pridavat fieldy/asociace. Doctrina vyuziva reflexi a pro ten field/asociaci musi existovat property, coz v runtime neudelas.
Takze me napadaji dve reseni:

1. ty rozsirujici parametry v adresar a eshop si das do traity a v aplikaci pak vytvoris entitu, kam das pozadovane traity
2. user v adresar a eshop nebudou nijak rozsirovat tu puvodni entitu, ale budou to samotne entity s asociaci na tu orig.

Takže jsem něco málo zkoušel a asociace jdou docela jendoduše udělat dynamicky pomocí eventů, má to akorát jeden háček, v entitě musí být definována property oné asociace :( Takže asi víc než ty dvě zmíněné možnosti nelze vymyslet.

@TomášVotruba jo traity sou ok, ale pak už by ty moduly nebyly na sobě nezávislé. Já chtěl nějak vyřešit že bodou třeba 3 moduly co jsem zmínil a bude moct fungovat libovolná kombinace, třeba uživatele + adresář, nebo uživatelé + adresář + eshop a nebo se použije jiný modul adresáře co bude fungovat jinak. Ideou bylo je mít nezávislé na sobě a třeba pomocí těch událostí aby se vzájemně dokázaly propojit.

@TomášVotruba ee to myslím že není ono. Doctrine embeddables pokud jsem dobře pochopil udělají to že si entitu rozšíříš o další property. Já to asi zkusím těma traitama a vymyslet nějaký generátor co by mě to spojil.

Ok, tak jsem došel k tomuto.

Problém:
Chci udělat databázi štítků. Jednou to bude jen název štítku, podruhé tam budou i nějaké další atributy. Když pak ten modul nastavím určím si, zda chci tohle nebo tohle.

Jak to zatím řeším:

interface ITag
{

}

/**
 * @ORM\MappedSuperclass
 */
class BaseTag extends BaseEntity implements ITag
{

	/**
	 * @ORM\Id
	 * @ORM\GeneratedValue
	 * @ORM\Column(type = "integer")
	 */
	protected $id;

	/**
	 * @ORM\Column(type = "string", unique = TRUE)
	 */
	protected $name;
}

/**
 * @ORM\Entity
 * @ORM\Table(name = "tag")
 */
class StandardTag extends BaseTag
{

}

/**
 * @ORM\Entity
 * @ORM\Table(name = "tag")
 */
class ExtendedTag extends BaseTag
{
	//nejake pridavne atrbity
}

v extension pak něco takového:

	public function getEntityMappings()
	{
		if(..){ //podminka, podle toho jako entitu tam chci soupnout
			return [
				'TagModule' => __DIR__ . '/../Model/TargetEntities/Extended/',
			];
		} else {
			return [
				'TagModule' => __DIR__ . '/../Model/TargetEntities/Standard/',
			];
		}
	}

	public function getTargetEntityMappings()
	{
		//zase if, zda chci slozity nebo lehci, stejny jako vyse
		return [
			'TagModule\Model\Entities\ITag' => 'TagModule\Model\TargetEntities\Standard\Tag',
		];
	}

Řešili byste to takto, nebo jinak? Asi běžnější proces je, že si tu konkrétní entitu nastavím v jiném modulu. Ale mě přijde lepší v tomhle případě, když jich bude nějaký konečný počet, mít to vše pod jedním modulem a nastavím si jen kterou použiju…

Druhá věc pak směřuje jak byste řešili vytvoření nové entity, abych si nějak vytáhl tu entity, co je resolved. Našel jsem tohle, ale příliš mi nesedí, není něco lepšího?

	$entityName = $this->tagRepository->getClassName();
	$tag = new $entityName();

ako potom niekde v module vytvorit novu entitu typu Entity\IArticleGallery?

A ked niekde v inom projekte budem potrebovat specificku verziu FakeGalleryEx tak to budem prepisovat vsade? :D

ako prve ma napadlo nieco taketo:

$className = $entityManager->getRepository(Entity\IArticleGallery::class)->getClassName();
$article = new $className();

napriklad spominany Sylius to riesi sposobom:

class EntityRepository extends BaseEntityRepository implements RepositoryInterface
{
    public function createNew()
    {
        $className = $this->getClassName();
        return new $className();
    }

	...
}

Já si obecně na entity (nejen pro Doctrinu) rád píšu továrničky, defaultně využívám generované z Nette, protože se občas může stát, že je potřeba po vytvoření každou entitu nějak nakonfigurovat trochu víc, než na co stačí defaultní hodnoty, a pak je člověk rád když nemusí hledat kde všude v kódu se používá new Entity.

V tomhle případě bych si napsal jen obecnou továrničku vracející interface, kterou bych pak ručně implementoval pro každou konkrétní entitu.

interface IArticleGalleryFactory {
  /** @return IArticleGallery */
  function create();
}

class FakeGalleryFactory implements IArticleGalleryFactory {

  function create() {
    return new FakeGallery;
  }

}

Sice to pak bude v configu na dva řádky a ne jeden a je potřeba o jednu závislost víc v kódu (je to špatně? ono je možná fajn vidět hned v konstruktoru, že tahle třída někde vyrábí novou entitu…), ale to snad není moc problém ;-)

@DavidMatějka tyjo díky! Tohle mě nějak ani nenapadlo zkusit :-D

EDIT: ale ještě mě tak napadá, že zrovna v týhle situaci je stejně lepší si tu implementaci napsat, protože je to součást modelu. Mimo Nette to nebude fungovat.

Editoval Zax (15. 11. 2015 13:44)

@JiříNápravník Jsem trochu zmaten o čem přesně mluvíš. Co je EntityResolver a jak funguje?

@JiříNápravník Ten event by se myslím neměl vystřelit pokaždé. Ovšem co jsem teď zkoušel v mé aplikaci tak pro některé entity mi vyletí vždy a pro některé nikdy (pokud nesmažu cache). Tzn. možná je kešování nějak zabugované… Pěkně děkuju, nasadils mi brouka do hlavy a teď abych strávil den zjišťováním jak funguje keš Doctrine. :-D

@JiříNápravník Pokud jsem to správně pochopil tak ten event vyletí když cache driver vrátí false. Následně by se ty chybějící data měly do cache uložit což se buď nestane anebo stane ale uloží se z nějakého důvodu jinam než kde se pak hledají… A spíše bych řekl že to nebude mít co do činění s RTEL, ale půjde o něco obecnějšího – respektive pokud ne tak to nenajdu protože RTEL nepoužívám.

@DavidMatějka: hele teď jsem se k tomu zase dostal. Pokud jsem pochopil správně tvou myšlenu v bodu 2, tak by např. v adresářovém modulu, byla entita User která by dělala propojení mezi moduly je tak? Taková asociační tabulka.

class AddressBookUser
{
	// Vazba na entitu User z modulu Users
	private $user;

	// Vazba na entitu AddressBook z modulu AddressBook
	private $addressBook;
}

Nemohl bych pak samozřejmě udělat $userModuleEntity->getAddressBook() ale musel bych si najít AddressBookUsera a až na něm to volat. Což by snad ani nevadilo.

Dá se to tedy považovat za čisté řešení? Čeho se snažím dosáhnout je odstranění závislostí mezi moduly, minimálně obousměrné, tedy UserModul nebude nic vědět o AddressBookModul a bude mu jedno zda bude instalován nebo nebude, ale AddressBookModul bude mít závislost na UserModul, protože bude chtít rozšířit jeho funkcionalitu, resp. vzít si jeho data pro práci.

@Oli: dík za řešení, ale myslím že toto můj problém neřeší, pokud bych chtěl jeden modul rozšířit jen jedním modulem tak by to asi bylo dostačující, ale já právě potřebuju jeden rozšířit vícero moduly.

Př: Mám modul uživatel. Ten má entitu Uživatel a ta má v sobě nějaké základní data co tomu modulu stačí a pro běh úplně easy verze aplikace je dostačující. Jenže pak tam přibude adresář a eshop, takže adresář bude chtít rozšířit entitu uživatele od záznamy adres a eshop bude zase chtít rozšířit uživatele o jeho faktury a objednávky. Takže mě napadlo buď dělat nějaký PHPWriter co veme konfiguraci co by daly dohromady jednotlivé moduly a vygeneruje třídu která bude extendovat uživatele a bude implementovat traity daných modulů, něco jako generuje proxy doctrina. Jenže pak by byl problém že by to bylo generované a IDEčko by se z toho mohlo posrat :D ale asi by to fungovalo. A nebo teda řešení jak jsem popsal vyše, resp. jak uvedl David Matějka

A @JiříNápravník se omlouvám že mu tu okupuju téma které je trošku jiné :D