YetORM – kvaziORM nad Nette\Database

Podporuje to i pěkný zápis do entity? Něco jako:

<?php
$book->addTag('foo');
$book->removeTag('bar');
?>

Editoval Šaman (10. 2. 2013 16:51)

Líbí se mi, jak je to jednoduché. Používám totiž ORM, které toho umí asi 10× víc, ale někdy je docela hukot se v tom vyznat a beztak většinou využijete jenom ten základ.

Ale to nezní moc nenávistně… takže mi tady schází hlavně tyto věci:

• Magie, aby člověk nemusel pořád copypastovat ty pořád stejné [gs]ettery. Co třeba @property, @property-read apod.?
• High-end CRUD operace, které by dělaly v podstatě totéž, co ty low-end, co tam jsou, ale proháněly by ta data přes entity, takže by na nich fungovala validace, custom setters atp.
• Taky si nejsem jistý tou metodou rollback(). Přidal bych kontrolu, jestli $transactionCounter === 1, jinak exception.

Moc hezký výtvor, líbí se mi „tenkost řešení“. Příkladný poměr počtu řádků a vytvořené hodnoty :).

Na llookův popud jsem (zatím v boční branchi) přidal podporu pro anotace nahrazující primitivní gettery a settery.

Podporované jsou @property pro getter i setter a @property-read pro getter. Anotace je třeba zapsat kompletně, tj. i s typem, na který se hodnota přetypuje. Anotací lze využít jen pro primitivní datové typy.

Následující definice entity jsou ekvivalentní:

EDIT:

Místo předchozího přetypovávání se nyní striktně kontroluje typ, jinak se vyhodí výjimka (podle toho jsem i upravil kód níže).

1. ruční gettery/settery

class Book extends YetORM\Entity
{
	function getId()
	{
		return (int) $this->row->id;
	}


	function getTitle()
	{
		return (string) $this->row->title;
	}


	function setTitle($title)
	{
		if (!is_string($title)) {
			throw new Nette\InvalidArgumentException("Invalid type - 'string' expected, '" . gettype($title) . "' given.");
		}

		$this->row->title = $title;
		return $this;
	}
}

2. využití anotací

/**
 * @property-read int $id
 * @property string $title
 */
class Book extends YetORM\Entity
{}

Interně se tedy properties nastavují instanci ActiveRow spjaté s instancí entity. Pokud je zároveň definována anotace spolu s ručním [gs]etterem, přednost má ruční definice. Stejně tak je upřednostňováno výchozí Nette\Object properties chování. Při volání [gs]et<Property>() se převádí z CamelCase na podtržítkové jméno.

Příklady:

$book->setTitle('Book title'); // ekvivalentní s $book->title = 'Book title';
$title = $book->getTitle(); // ekvivalentní s $book->title
$book->setId(123); // zhavaruje, $id je read-only

Editoval uestla (1. 4. 2013 17:51)

Bude to schopné si poradit i s výsledkem přes query (tedy Statement místo Selection)?

@uestla například, když potřebuješ vytvořit dotaz s joinem do stejné tabulky. NDB neumí pracovat s aliasy…

Díky, Šamane. Na doplňky to je možná ještě brzy,
teď mně ještě chybí nějaká možnost kešování – entity
nejde serializovat :-(

Nicméně jestli máš zpracovaný příklad a nebudeš proti,
můžeš mi ho poslat jako pullík na github coby README ;-)

To mě těší. Komunitnímu vývoji se absolutně nebráním, čili pokud
chce kdokoli čímkoli přispět, jsem jedině pro.

Co se composeru týče, s tím pořád nejsem kamarád, používá-li
někdo YetORM a kamarádí se s composerem, budu rád za pullík.

A k budoucímu vývoji: právě se snažím rozumně rozšířit properties,
aby šlo deklarovat i typ coby třídu (čili rozšířit současný stav,
kdy jsou podporovány pouze primitivní datové typy).

Pokud mně, nebo někomu jinému, bude při používání chybět nějaká
funkcionalita, klidně to můžeme prodiskutovat a přidat, není problém.
Zatím jsem to použil asi 3krát, a celkem mi to vyhovuje.

Těší mě, že to někomu pomůže, nicméně zdržel bych se zatím
názorů o zařazení přímo do Nette, na to je to ještě v moc raném
stádiu a připouštím, že to má i nějaké mouchy (viz výše).

Díky!

@Tharos To by bylo super, a kdybys do toho zakomponoval ještě multijazyčnost, klidně by to mohlo být pokračovatelem po quick startu.

uestla napsal(a):

Co se composeru týče, s tím pořád nejsem kamarád, používá-li
někdo YetORM a kamarádí se s composerem, budu rád za pullík.

Pullík, přidej si tam akorát "license": "..." a zaregistruj si to na https://packagist.org/.

A ještě by to asi chtělo upravit testy, aby používaly Nette a PHPUnit z composeru.

Editoval mkoubik (31. 3. 2013 14:46)

Ahoj,

narazil jsem na jednu věc, která mi aktuálně vcelku dost chybí. Než ale pošlu pull request, chtěl bych to probrat ještě tady…

Mějme propertu Entity zapsanou přes anotaci, která může nabývat hodnoty null. V anotaci by se to pak standardně zapsalo jako string|null, null|string, string|NULL, nebo NULL|string. S tím si teď ale ORM neporadí.

Nejjednodušším možným řešením je prostě kontrolovat, jak typ začíná nebo končí, a podle toho null hodnoty povolit. Problém je, že si to ale neporadí třeba se zápisy string|null|bool. Otázka je, zda takové zápisy mají vůbec smysl? Byť jsou syntakticky správné. Problém by s nimi byl samozřejmě i u automatického __set, kde by ORM nevědělo, na který typ vlastně přetypovávat.

To nejjednodušší řešení mám naimplementované a mohu poslat. Pokud bys ale chtěl něco sofistikovanějšího, dej vědět.

Editoval Tharos (2. 4. 2013 10:13)

Vidím to úplně stejně. Mám teda připravit pull?

Spolu s tím bych rád vyzkoušel i dekomponování parsování těch property anotací do samostatné třídy (např. YetORM\EntityReflection extends Nette\Reflection\ClassType). Mělo by to několik výhod: parsování anotací by proběhlo zase jenom jednou a ne při každém přístupu k __get/__set, šlo by pak odstranit ty (IMHO ošklivé) výstupní parametry (&) a spolu s tím by šlo hezky vyřešit i problém s null.

No, já to u sebe takhle připravím a pak uvidíš, jestli to bude kompatibilní s Tvými představami. :)

Editoval Tharos (2. 4. 2013 13:29)

Tak jsem si s tím pohrál a výsledek můžeš vidět v téhle mojí brenši. Jelikož to byl poměrně hluboký zásah, pull request zatím neposílám. :)

Tak nějak by to mělo řešit vše, o čem jsem psal ve svém předchozím postu…

No ale mám v tom i jeden BC break. Vypustil jsem to automatické přejmenovávání názvu fieldName → field_name, protože já v databázi sloupce pojmenovávám lower-CamelCasem (například bookTitle) a přes tu Tvou konverzi u mě nejel vlak. :) Podtržítko používám pouze u sloupců, které nesou cizí klíč (například author_id).

Nabízím, že tam ten převod doplním jako nějaký adaptér. Zkrátka si myslím, že podobná konverze by měla být spíš snadno doplnitelná a ne zadrátovaná v core kódu. Já jsem si kvůli tomu pro své bookTitle sloupce musel psát get/set metody…

Dej vědět, co si těch mých úpravách myslíš a pokud by Ti to vyhovovalo, pošlu pull request.

Editoval Tharos (2. 4. 2013 23:28)

Nemáš zač, pořád se cítím dlužníkem. :)

Ad adaptér) Napadlo mě ještě jedno řešení, úplně snadné:

/**
 * @property string|null $bookTitle %book_title
 */
class Book extends YetORM\Entity
{
}

Prostě by se vymyslela syntaxe pro zápis názvu sloupce tabulky (pokud se liší od názvu property) přímo v anotaci. Co si o tom myslíš? Implementačně triviální a snad vše řešící.

Ad třidní properties) To by mělo být to nejmenší.

Refaktoruji do YetORMu jednu menší aplikaci, která má ale poměrně košatý model. Beru to jako takový křest ohněm. :) Zatím to jde hladce a postupně mi krystalizují na povrch všemožné drobnosti, které za běhu v ORM ladím. Mimochodem povedlo se mi vcelku snadno namapovat jednu entitu rozlezlou do více tabulek – do jedné „hlavní“ a jedné „doplňkové“, a to ještě tak speciálně, že pro některé entity záznam v té doplňkové tabulce vůbec nemusí být. Tohle se mi zatím s žádným jiným ORMkem tak elegantně namapovat nepodařilo. :)

Až si dohraji, udělal bych z toho nějaký závěr a připravil bych pull request. Kód udržuji minimální, za sebe bych byl opravdu nerad, aby ORM nějak kynulo. Sepíšu, co a proč jsem upravil a pak nechám na Tobě, jestli to začleníš.

Ahoj,

tak jsem k sobě pushnull ty mé nedávné úpravy. Teď jsou ve větvi dev, tu EntityReflection jsem už u sebe začlenil do masteru. Stručně k mým změnám a k tomu, co mě k nim vedlo:

Drobné rozšíření EntityReflection
Nově umí jednorázově zmapovat settery a gettery. Logicky to do této třídy patří a dá se toho využívat v Entity::toArray (viz dále) a také v Entity::checkValidity (viz dále).

Přidána metoda Entity::checkValidity
Metoda, která se z entity pokusí postupně načíst všechny položky a u těch, které nejsou read-only, je na ty hodnoty opět nastaví (stav se tedy nijak nezmění). Pěknej nesmysl, že jo. :) Ale jen na první pohled. Díky této akci protečou zapouzdřená data skrze všechny gettery a settery a vyhodí se výjimka, pokud je někde nějaká nekonzistence. Využívám toho hlavně při vytváření záznamů.

Upravena metoda toArray()
Nebavilo mě ji pro každou entitu s vazbami upravovat. Nyní si poradí i s navázanými entitami a kolekcemi entit – jednu úroveň vypíše kompletní, další úrovně jen informativně. Hezky je to vidět v testech. To, že se hlubší úrovně vypisují jen informativně, řeší problém s kruhovými závislostmi při konverzi.

Přejmenována metoda toActiveRow
Tohle je taková otázka. Úspěšně mapuji v jednom případě dvě tabulky (1:1) do jedné entity a když taková entita podědí metodu toActiveRow, je to divné, protože ona v sobě zapouzdřuje dvě instance ActiveRow. Přemýšlel jsem, na co by to šlo přejmenovat a vyzkoušel jsem decapsulate. :) Název vychází z toho, že entita zapouzdřuje (encapsulates) nějakou vnitří reprezentaci (typicky jeden ActiveRow) a pro pár speciálních účelů (persistence, výmaz) je výhodné tu vnitřní reprezentaci dostat ven. Decapsulate mi přišel vhodný termín :). Ale tohle je určitě k diskuzi, vím, že to není obvyklé sloveso.

Tak si to projdi… Snažil jsem se dodržet coding style a testy samozřejmě procházejí (samozřejmě jsem je vhodně upravil, hlavně aby reflektovali úpravy v toActiveRow). Kdyby se Ti to celé líbilo, klidně můžu poslat pull request. :)

Jinak ve volných chvílích bych tedy ještě doimplementoval tu možnost definice názvu sloupce u property a také podporu pro „hintování“ ostatních entit. Pak bych taky dopsal testy pro té mé nové funkce.

Pak by to bylo z mého pohledu úplně dokonalé :).

Editoval Tharos (5. 4. 2013 22:48)

Hmm, tak to je hezký… Pokud se přejde ze __set na update(), elegantní persistence půjde do kytek. Při zachování současného stylu by se pak musela ukládat každá změna samostatně… takže pytel dotazů kvůli jedné entitě.

Takže pevně doufám, že se ta změna nakonec z 2.1-dev vypustí…

Edit: Prošel jsem si bleskově debatu na GitHubu a asi nevidím úplně do detailů Nette\Database… Dá se v pár větách shrnout, co je na těch metodách špatného a proč by měly být deprecated?

Editoval Tharos (6. 4. 2013 0:00)

Stavíme-li na něčem, co je v „divokém“ vývoji, asi bychom s tím měli počítat… Update se volá z Repository, čili bude to sice psaní navíc (možná nějaký podobný mechanismus jako býval v ActiveRow::__set() půjde převzít), ale fatální by to být nemělo… Ať už bude entita spojovat jednu nebo více tabulek…

@Tharos

Přejmenována metoda toActiveRow
Tohle je taková otázka. Úspěšně mapuji v jednom případě dvě tabulky (1:1) do jedné entity a když taková entita podědí metodu toActiveRow, je to divné, protože ona v sobě zapouzdřuje dvě instance ActiveRow. Přemýšlel jsem, na co by to šlo přejmenovat a vyzkoušel jsem decapsulate. :) Název vychází z toho, že entita zapouzdřuje (encapsulates) nějakou vnitří reprezentaci (typicky jeden ActiveRow) a pro pár speciálních účelů (persistence, výmaz) je výhodné tu vnitřní reprezentaci dostat ven. Decapsulate mi přišel vhodný termín :). Ale tohle je určitě k diskuzi, vím, že to není obvyklé sloveso.

S tímhle mám trochu problém – jestli to dobře chápu tak v tvém případě metoda decapsulate u té entity co zapouzdřuje dva ActiveRow vrací něco jiného, což je špatně. Metoda by měla vždy vracet stejný typ. Samozřejmě pokud vrací tvou vlastní implementaci Nette\Database\Table\IRow, je vše v pořádku.

Zatím se spíše inspiruji. Snažím se nedělat zbytečně moc razantní změny…

Ohledně Reflection jsem šel podobnou cestou – vznikla branch reflection, ve které přibyl namespace Reflection sdružující logiku propert (na to, že jde o alternativní funkcionalitu týkající se zápisu anotací, to vyhřezlo celkem pěkně :-) ).

Přidal jsem tam rovnou i podporu zápisu jména sloupce, funguje takto:

/** @property string $bookTitle -> book_title */
class Book extends YetORM\Entity
{}

Díky tomuto zápisu pak mohu používat následovně:

$book->bookTitle = 'title'; // odpovídá $book->row->book_title = 'title'

Do téhle větve bych přidal podporu pro třídní typy z properties větve. No a až přijde správná chvíle, tak to hodím do masteru.

Sorry za offtopic: Pro dibi orm pouzij http://orm.petrprochazka.com/ a neblazni.

<offtopic>
@castamir Musím se zde PetrOrmu zastat, jde o výborně navržený nástroj, který je především flexibilní (!), a zároveň se s ním dá de facto rychle prototypovat.

Dokumentace bohužel neexistuje v ucelené formě, ale velké množství detailně popsaných informací přímo od autora lze najít na fóru.

Ad nedokončené: za to je profesionálně vyvíjené s extrémním důrazem na zpětnou kompatibilitu.
</offtopic>

Editoval vojtech.dobes (7. 4. 2013 12:05)

Právě jsem mergnul reflection do masteru – což způsobilo BC break u defaultní propertyName ⇒ column_name konverze – tu je případně třeba dělat ručně (příklad výše).

Co se nekompatibility s Nette-2.1-dev ActiveRow::update() týče, zatím úpravy zařazovat neplánuji, mám rozpracovaný pokus, ale vzhledem k větším odlišnostem (SelectionFactory, apod.) a možnosti dalších změn ještě s jakoukoli finalizací počkám…

Souhrn změn oproti předchozí „verzi“ masteru:

• podpora třídních typů v properties (např. @property DateTime $written)
• podpora NULL typu v properties (<type>|NULL)

Velké díky Tharosovi za přispění!

Editoval uestla (9. 4. 2013 14:10)

Otagováno coby verze 0.9.1.

@Jack06: Zkus upravit getSections():

/** @return \YetORM\EntityCollection */
public function getSections()
{
	return $this->getMany('ArticleModule\Section', 'article_has_section', 'section');
}

Brát to relativně by vedlo k hromadě problémů. Možná tě potěší, že v PHP 5.5 už půjde napsat

/** @return \YetORM\EntityCollection */
public function getSections()
{
	return $this->getMany(Section::class, 'article_has_section', 'section');
}

Ještě jednu otázku bych měl, jak řešit (nějaká reflection??), Když mám entitu Article, ale tabulka v databázi se bude jemenovat jinak, třeba bude mít prefix?