YetORM – kvaziORM nad Nette\Database

Jak tabulka, tak entita se dají zapsat buď anotací, nebo třídní proměnnou:

/**
 * @entity My\Super\Entity
 * @table my_glorious_article_table
 */
class ArticleRepository extends YetORM\Repository
{}

nebo

class ArticleRepository extends YetORM\Repository
{
	protected $entity = 'My\Super\Entity';
	protected $table = 'my_glorious_article_table';
}

Editoval uestla (15. 4. 2013 17:56)

@K0nias: Proč si to myslíš? Dle mého je současné chování v pořádku. To na jaký sloupec se mapuje createDate je interní detail té entity.

@K0nias: Já to chápu, ale považuji to za úmysl a ne chybu.

Já to ve svém orm řeším tak, že data entity držím ve formě, ve které se s nima dá krásně pracovat (např. databázový sloupeček typu SET udržuju jako pole, datum a čas jako DateTime apod.). V případě uložení entity tam mám metodu, která mi data připraví tj. doplní nevyplněné položky defaultními hodnotami, odkazy na jiné entity nahradí jejich primárním klíčem, naformátuje datum a čas a na závěr ověří, zda jsou všechny údaje vyplněny. Takto to vypadá složitě, ale implementace je poměrně jednoduchá.

Editoval castamir (18. 4. 2013 17:32)

To ste me teda moc nepotesili panove. :) Uz jsem to prepsal

KOnias: Entita by navenek neměla být závislá na pojmenování sloupců databáze. Ale díky, žes nakousl tenhle problém, protože současný stav „odstíněnosti“ od názvu sloupců mi ne úplně vyhovuje a přemýšlím o zlepšení.

Mám konkrétně na mysli řazení a podobné radosti prováděné na EntityCollection. Už na téhle úrovni by měl člověk řadit podle jmen propert a nikoli podle jmen sloupců, jak je tomu teď.

Problém je, jak zapsat řazení podle property spřažené entity – teď třeba seřadím pohodlně díky

$books->orderBy('author.name');

Ale toto jsou jména sloupců…

Jak řešíte například triviální výběr jednoho záznamu, stejně jako například unikátního kde ID, ale podle jiného sloupce?

něco jako toto, což nelze používat:

public function findByUser($key)
{
	return new Settings($this->getTable()->where('user_id', $key));
}

EDIT: Tak nevím proč, ale po x refreshích už to jede v pohodě. Díky

No dobrá, to jsem zkusil a přišel jsem na to, že když toto udělám, tak mi nette panel hlásí 2 naprosto stejné dotazy na databázi. To by se asi stát nemělo ne?

Dokud tam nedám to fetch, tak mám dotaz na db jeden, jakmile přidám fetch, tak mi hlásí dotazy 2.

viz obr

uestla napsal(a):

@Jack06 Protože

$this->getTable()->where('user_id', $key)

nevrací ActiveRow, ale Selection, čili použij

$this->getTable()->where('user_id', $key)->fetch()

Editoval Jack06 (26. 4. 2013 19:00)

Dědičnost asi až tak uplně nefunguje nebo ano?

UserEntity: http://pastebin.com/9Q0T7FMp
AbstractEntity: http://pastebin.com/kEdvw17r

Když si dám get na user, tak se mi vrátí pouze proměnné definované v userEntitě, nikoli všechny.

Tak jsem to zkusil přepsat:

Abstract: http://pastebin.com/BjvqF05K
User: http://pastebin.com/C2RdgpTT

A bohužel stále to samé, sql mi vrací z databáze pouze sloupce z User

Šaman napsal(a):

Domnívám se, že tohle ti nebude fungovat už z principu – anotace nejsou součást jazyka PHP a zpracovávají se pomocí Nette při vytváření instance dané třídy. A jestliže tu abstraktní třídu neinstancuješ, tak poděděná třída o anotacích svého předka vůbec neví. V tomto případě bys musel definovat všechny property a metody klasickým PHP způsobem, pak to bude samozřejmě i dědit.

Repository: http://pastebin.com/9Vj59qkZ
Database: http://www.2imgs.com/68dc2f05d6

Mám to v jedné tabulce a záznamy vybírám pomocí fetch. Vrací mi to následující: http://www.2imgs.com/5bef1c36e5

// Když to hodím z abstractu do User, tak to funguje.

Editoval Jack06 (27. 4. 2013 10:53)

Teď nechápu k čemu bych měl a jaké property definovat, když je to YetORM. Ten vrací stejně $this->row a ne lokální. Popravdě ani v examples na gitu YetORM nevidím nic víc, než mám napsané.

Šaman napsal(a):

A zůstaly ti v těch entitách nějaké property? Takhle se skoro divím, že ti to vůbec něco načítá (kromě id_user).
Zkus si v abstraktní třídě definovat pár property klasicky v PHP, jako public.

Nepoloží to další dotaz na databázi, normálně se jen ten sloupec přidá do sql dotazu, ale jelikož pracuji se záznamem jako s entitou a strkám to jako setDefaults do formuláře, tak i přesto že v sql dotazu pak je třeba ten sloupec z abstractu, tak se mi ale ve vytvořené instanci User neobjeví.

Toto mi přijde jako hodně velké mínus, když nefunguje takto dědičnost. :-(

Šaman napsal(a):

Sorry, máš pravdu, právě jsem to zkoušel.. Bohužel, to, že YetORM vrací hodnoty pomocí ActiveRow je jeho hlavní vlastnost, ale pro mě je to zároveň největší slabina..
Asi ti neporadím – předpokládám, že metody z Abstract (pokud nejsou v anotacích) ti fungují, jen si pokladají dalši dotazy?

@Jack06: Předpokládám, že se tu jedná o použití metody toArray(), a že ruční volání getteru z rodiče funguje standardně…

Je to pravda, gettery to vrací pouze z nejnižší úrovně, což tam bylo z důvodu, aby se nezanášely nějakými interními gettery na úrovni YetORM\Entity. To už ale není třeba.

Implementováno. (včetně dědičnosti anotovaných propert)

@Šaman: V čem vidíš onu slabinu? Z ActiveRow se berou pouze property, pokud chce člověk složitější logiku, může si napsat getter…

Editoval uestla (27. 4. 2013 14:27)

@Šaman: To máš pravdu. Tohle mi vadí taky. Paradoxně tohle možná vyřeší úpravy ActiveRow chystané pro Nette 2.1, kvůli kterým bude nutné YetORM upravit.

Zatím si to tak spojuji v hlavě, ještě jsem nic nenapsal, ale nejspíš konstruktor upravím na

function __construct(YetORM\Row $row = NULL)
{
	$this->row = $row;
}

Třída YetORM\Row bude extendovat ActiveRow s tím, že zachová __set() ze stávající stable verze, a upraví update() na něco jako

function update()
{
	$tmp = $this->modified;
	$this->modified = array();
	return parent::update($tmp);
}

EDIT: S tím, že persistence na straně repository by mohla vypadat

function persist(& $entity)
{
	$row = $entity->toRow();
	if ($row === NULL) {
		$entity = new Book($this->getTable()->insert($row->get<CoolNázev>()));

	} else {
		$row->update();
	}
}

EDIT2: Ale jak jsem už předeslal, do vydání stable verze Nette na tuhle funkcionalitu nešáhnu, navíc to bude chtít pořádně osázet testy.

Editoval uestla (27. 4. 2013 16:55)

OT:
@Tharos: těch vlastních ORM je tu poslední dobou jak hub po dešti. Taky si dělám jeden nad dibi :D

Co máte proti ORMům? ORM je mapper, který zařizuje ukládání Entit jako objektů do relační databáze a naopak. Píšu ho pro každý projekt od té doby, co jsem začal data udržovat v Entitách místo v polích.

Vy myslíte ORM framework. Nad Dibi už docela dlouho píše takový ORM framework Petr Procházka, dokonce už má RC verzi. Ještě se podívám, jesli existuje dokumentace, protože to je často kámen úrazu. YetORM má tak málo kódu, že se většina věcí dá vyčíst z kódu, u Petrova ormu ne.

OT
@Šaman ORM je obecně model na ukládání dat. Co se ORM Petra Procházky týče, díval jsem se na něj a mnoho věcí mi na něm vyloženě vadí a nejsou to zrovna maličkosti, ale pro mě dost zásadní věci (od struktury frameworku, přes propojení entit s repozitářem a mapperem až po ukládání). Spoustu věcí má fakt vymakaných (hlavně vazby mezi entitami), ale přes ten způsob ukládání a napojení té struktury se prostě nedokážu přenést.

@castamir Nedelal jsem to jako fork na githubu, protoze je to kompletne prepracovane, ale jasne to vychazi z YetORM, takze bude zachovana licence, autorstvi, atp… :)

@hrach a zveřejníš to někde?

Blahoželám k významnému pokroku. :)

Persistence, jak jsi naimplementoval, pro mě osobně skrývá pár myšlenek k zamyšlení. Rád bych je zde zveřejnil, protože je teď aktuálně také řeším v tom svém mapperu nad dibi.

Co vypíše následující kód? A co by vůbec měl vypsat?

$author = $book->getAuthor();
$author->setName('Franta');

$author = $book->getAuthor();
echo $author->getName();

„Franta“, anebo snad něco jiného?

Kam tím mířím je, že u takhle pojaté persistence mi v hlavě naskakuje hned několik scénářů, kdy nemám jasno, co dostanu za výsledek. Ba co víc kdy nemám ani jasno v tom, co bych sám v takové chvíli chtěl… Prostě je to pro mě neintuitivní.

Mé současné řešení funguje tak, že entity jsou read-only (mají jenom gettery) a vytváření (respektive úpravy) záznamů se dějí přes repositáře stylem $bookRepository->createBook('Some book', 2, 'some description') (respektive $bookRepository->update(1, $values)).

Je to asi trochu divné, ale ve své podstatě praktické a chování je jasné. Také to je hezky kompatibilní s typickým scénářem, kdy dostanu data z formuláře a mám z nich něco uvařit. Zápis:

$book = new Book;
$book->setTitle('Some book');
$book->setAuthor($author);
$book->setDescription('some description');
$bookRepository->persist($book);

mi prostě přijde neohrabanější oproti prostému (a navíc atomickému):

$bookRepository->createBook('Some book', 2, 'some description');

Protože je to ale asi trochu neobvyklý přístup, váhám, zda si persistenci přes settery a persist() přece jen nenaimplementovat. Jen v ní cítím dost WTF záležitostí – asi bych byl schopen vysypat z rukávu množství dalších ukázek, kde bych intuitivně nevěděl, co mohu očekávat za výsledek… Nebo to vidím moc černě?

Editoval Tharos (16. 5. 2013 9:35)

Zauvažuj nad přejmenováním složky E např. na Exceptions ..... Bude to lepší ;)

Malý update:

Reakce na Jack06a: Přidal jsem podporu pro zápis entit v anotacích, který zohledňuje aliasy. Využívá se k tomu Aliaser.

POZOR: týká se to opravdu jen anotací, pokud píšeme třídu do řetězce, je třeba uvést její celé jméno, např. v

new YetORM\EntityCollection($selection, 'Model\Entities\Book');
// nebo

class BookRepository
{
	protected $entity = 'Model\Entities\Book';
}

Přepsal jsem testy tak, aby využívali namespace a bylo názornější, jak to používat.

Ahoj, máš na mysli konkrétně znění?

Protože je všude uváděno MIT…

Ahoj, právě testuji knihovnu na jednom menším projektu a používá se opravdu jednoduše. Zajímá mě jestli plánuješ další vývoj, případně podporu výčtového typu enum nebo definici vazeb pomocí anotací. Díky