YetORM – kvaziORM nad Nette\Database

Možné to není, protože mě nepustí YetORM výjimka. Napadá mě to v téhle situaci třeba.
Ale rozumím tomu principu, asi je to tak čistější do budoucna.

Šlo mi to – dát si do té getMetody json_decode, přišlo mi, že to patří do Entity.

Díky za nullable.

Přemýšlel :-)

Dopadlo by to pak, že by se logika příslušící do YetORM\Repository přesouvala bůhvíkam a s internostmi Nette\Database by se operovalo na nevhodných místech. Proto jsem to tam nepřidával.

Zdravím,

s YetORM, resp. s Nette začínám a YetORM mě oslovila jako abstrakce, kterou jsem hledal :)

Řeším problém s transakcemi, které nevím jak správně s YetORM používat:

Pokud chci uložit entitu, která se skládá z dalších entit, tak to potřebuji obalit celé do transakce, abych měl v DB uloženy buď kompletní data nebo nic.

Jak tedy realizovat transakce, pokud ukládám několik různých entit do různých repository?

Děkuji za reakci :)

Zatím to řeším přidáním metody insert do Repository, která provede insert nad NDB, a transakce si řeším ve vrstvě nad Repository také nad NDB, ale není to čisté řešení a moc se mi nelíbí.

Stav kdy by se řešili transakce bokem, nezávisle na Repository by byl fajn :)

Ahoj,
mám dotaz ohledně vytváření entit z relací.
Mám entitu book a v ní následující metodu

function getAuthor()
	{
		return new Author($this->record->author);
	}

Vadí mi to new. Neměl bych si spíš do té entity předat relaci která vytváří Author entitu a zavolat něco jako

	function getAuthor()
	{
		return $this->authorRelation->createEntity($this->record->author);
	}

Je mi jasné že vazbu na author relation bych musel dát i do book relatin a ta by ji předávala svým entitám, ale přijde mi, že jsou tak dodrženy principy DI.

Nebo mi něco uniklo?

Editoval mdsystem (11. 5. 2015 15:08)

uestla napsal(a):

Většinou si při složitějších vazbách udržuji službu EntityCreator, která má metody createAuthor($row) apod. Tu si pak konstruktorem předávám do jednotlivých entit, aby tak vytváření instancí probíhalo prostřednictvím téhle služby.

Díky za odpověď.
Samozřejmě jsem to napsal před tím blbě. Tím authorRelation jsem myslel authorRepository. Nicméně jestli jsem tě správně pochopil, není špatně pokud entita zná repository (což je také služba), kterou nechá jinou entitu vytvářet. To jestli to zabalím ještě do nějaké obecné služby (tvá EntityCreator), už podle mě není podstatné. Prostě není problém, aby entita volala createEntity metodu nějaké repository.
Šlo mi o to jestli tím nějak nejdu proti myšlence ORM.

Editoval mdsystem (12. 5. 2015 1:39)

uestla napsal(a):

Předávat repozitory je neprozíravé v tom, že pokud jsou entity na sobě závislé vzájemně, dostaneš se do cyklické závislosti uvnitř SystemContaineru. Proto si vytvářím nezávislou EntityCreator, kterou si předávám jak do entity, tak do repozitářů. V repozitářích si pak akorát upravím createEntity() tak, aby volala metodu právě oné služby.

Jo, tak už jsem na to také přišel. Když se dva repository potřebují v konstruktoru navzájem, není to úplně ono 8o). Jen mi to nejdřív přišlo ne úplně pěkné mít službu, která zná v podstatě všechny repository.

Služba EntityCreator nezná všechny repozitáře, jen všechny závislosti všech entit. Ale to je jen proto, že jsem si to tak zvolil. Můžou existovat tenčí továrničky pro každou entitu zvlášť.

Ohledně EntityCollection – to, co popisuješ, funguje, tj. místo názvu entitní třídy jde předávat callback, tj. např. Nette\Utils\Callback::closure($entityCreator, 'createAuthor').

uestla napsal(a):

Většinou si při složitějších vazbách udržuji službu EntityCreator, která má metody createAuthor($row) apod. Tu si pak konstruktorem předávám do jednotlivých entit, aby tak vytváření instancí probíhalo prostřednictvím téhle služby.

Ahoj,

šlo by prosím postnout ukázku takové služby? Potřeboval bych trošku „nakopnout“ :)

Díky

Verze 9.0.0

Před malou chvílí jsem vydal verzi 9. Hlavní změnou je přidání CI a code coverage.

Došlo také k pár změnám a menším BC breakům (proto navýšení major verze).

Velké díky za pomoc patří @Felix ! :-)

Ještě drobnost k nové verzi. Proč checkEntity zůstala private? Mohla by být protected? :) To je prakticky jediný věc, kvůli které „forkuju“.

Use-case, dědím si Repository do BaseRepository a při každém volání persist() ukládám odlitek změn někam do „historie“.

@uestla: Nějakým zázrakem jsem pochopil, jak udělat PR na Githubu.

Jak vkládat do M:N tabulky?
ZKoušel jsem to klasicky přes vlastní repozitář + entitu, ale hází mi to chybu při volání setRow s integerem.
https://ctrlv.cz/AP97

Ještě přidám jak to volám

$MNEntity = $this->MNRepository->createEntity();
$MNEntity->id1 = $id1;
$MNEntity->id2 = $id2;
$this->MNRepository->persist($MNEntity);

Editoval CZechBoY (8. 4. 2016 20:04)

Ahoj, bude oficiálně nahrazení nette/object za trail?

CZechBoY napsal(a):

Jak vkládat do M:N tabulky?
ZKoušel jsem to klasicky přes vlastní repozitář + entitu, ale hází mi to chybu při volání setRow s integerem.

Přidal jsem do Repository::persist() kontrolu a snad i lepší chybovou hlášku :-)

Ahoj,

defaultní jazyk bych držel v repozitáři a upravil v něm metodu createEntity(), kde bych do entity vložil defaultní jazyk.

Pak bych přidal metodu Post::getTranslation($lang = NULL), která by vracela spřaženou instanci PostLang podle jazyka – pokud by byl NULL, vrátila by defaultní překlad. Instance bych navíc cachoval, abych ušeřil dotazy.

Všechny následné metody Post::getTitle() apod. by měly volitelný parametr $lang, který by vracel hodnoty z instance překladu.

Tedy vše výše uvedené v kódu (psáno na koleně):

class PostRepository extends YetORM\Repository
{
	private $defaultLang = 'en';

	public function createEntity($row = NULL)
	{
		$class = $this->getEntityClass();
		return new $class($this->defaultLang, $row);
	}
}


class Post extends YetORM\Entity
{
	private $defaultLang;
	private $translations = [];

	public function __construct($defaultLang, $row = NULL)
	{
		$this->defaultLang = $defaultLang;
		$this->record = Record::create($row);
	}

	public function getTranslation($lang)
	{
		if (!isset($this->translations[$lang])) {
			$row = $this->record->related('post_lang', 'post_id')
					->where('lang_id.code', $lang)
					->fetch();

			$this->translations[$lang] = new PostLang($row);
		}

		return $this->translations[$lang];
	}

	public function getTitle($lang = NULL)
	{
		return $this->getTranslation($lang ?: $this->defaultLang)->getTitle();
	}
}

Snad ti to alespoň ukázalo možný postup :-)

Kdybys něčemu nerozuměl, zeptej se.

Editoval uestla (20. 12. 2016 10:26)

Ahoj @uestla, chtěl bych přetížit AnnotationProperty – nenapadá Tě hezký způsob jak na to? Nechce se mi jít do forku – spíše kdyby to šlo rozšiřovat pomocí interface. Připravím PR klidně, jen zatím vymýšlím jak na to.

Use case – chceme sami rozhodovat, kdy se má sloupec v ResultSet měnit v DateTime. Nelíbilo se mi, že pro každý sloupec, který má nastaveno date se tvoří v Nette (new DateTime) i když to není potřeba. Napsal jsem tedy driver, který to nedělá. V entitě bych však rád zachoval obojí chování v property nastavit jak string či DateTime a vytvoření new DateTime by byla zodpovědnost entity. Bohužel to neprojde přes tu kontrolu v AnnotationProperty#96. Díky.

@uestla: Ano – výkonnově se nám to moc nelíbilo.

Díky to je také dobrý nápad, chtěli jsme to mít programátorsky přívětivější, ale explicitní funkce bude čistější řešení i pro testování.