Promeo – vas novy model do Nette

CRUD operacie

Praca s datami je najcastejsi sposob akym programator pracuje s databazou a Promeo vzniklo za ucelom ulahcit a osladit
programatorovi zivot. Kazdy typ operacie preto disponuje aj masovou variantou, ktora umoznuje vytvarat, menit a mazat viacere zaznamy naraz.

Podme sa blizsie podivat na jednotlive ukony:

Pridavanie

Jednoduche

$users = new Promeo(':tp:users');

// vytvorime si entitu
$user  = $users->entity(
			'name' => 'John Doe',
			'email'=> 'john.doe@gmail.com',
		);
// pridame ju do databazy
$users->add($user);

V priklade mozeme vidiet pouzitu metodu entity(), jej ucel je jednoduchy, odprostit programatora od pouzivania konkretneho
nazvu triedy v kode a dosiahnut tak vyssi stupen abstrakcie. Metoda sa sama postara o vratenie korektne vytvorenej entity so
vsetkymi nalezitostami, ktore k tomu patria.

Za zmienku stoji tiez to, ze pokial je primarny kluc typu auto_increment, objavi sa novo vygenerovana hodnota priamo v entite.
V tomto pripade by sme preto mali nove ID uzivatela dostune cez $user->id.

Hromadne

$vouchers = new Promeo(':tp:vouchers');

// vytvorme si entity
for ($i = 0; $i < 5; $i++) {
	$voucher = $vouchers->entity(
		'check_code' => sha1(uniqid(mt_rand(), true)),
		'discount'   => mt_rand(0, 100),
	);
	// pridame entitu na zasobnik
	$vouchers[] = $voucher;
}
// pridanie entit do databazy
$vouchers->flushAdd();

Pri hromadnych ukonoch vzdy existuje viac sposobov ako ich zapisat, v priklade mozeme vidiet asi ten najintuitivnejsi a to je
$vouchers[] = $voucher. Medzi dalsie patri napriklad: $vouchers->add($voucher, FALSE), $vouchers['a'] = $voucher pripadne $vouchers['+'] = $voucher.
Kazdemu moze vyhovovat iny zapis, dobre je vsak zvolit si jeden a potom sa drzat toho.

Metoda flushAdd() vracia pole entit, ktore maju doplnene automaticky vygenerovane primarne kluce.

Zmena

Update entit funguje obdobne ako pridavanie.

Jednoducha

$users = new Promeo(':tp:users');
$user  = $users->get(3);
	$user->email = 'my.new.email@gmail.com';
$users->update($user);

Hromadna

$vouchers = new Promeo(':tp:vouchers');

// vytiahnime si iba poukazky s vysokou zlavou
$bigDiscounts = $vouchers->where('[discount] > 60')->getAll();

foreach ($bigDiscounts as $id => $voucher) {
	$voucher->discount -= 20; // znizime zlavu o 20%
	$vouchers['u'] = $voucher;
}

// hromadny update
$vouchers->flushUpdate();

Ako uz bolo nacrtnute vyssie, pri zmenach sa v query posielanej do databazy vyskytuju len stlpce, ktore sa naozaj zmenili, cim sa zvysuje vykon a
znizuje chybovost kodu. Samozrejme aj tu mame viacero moznosti zapisu. Metoda flushUpdate vracia pocet uspesne vykonanych zmien.

Mazanie

A do tretice, v jednoduchosti je krasa :)

Jednoduche

$users = new Promeo(':tp:users');
$users->delete(3); // odstrani uzivatela s ID 3

Hromadne

// predpokladajme, ze v $logs mame zoznam logov a chceme vymazat tie, ktore su
// starsie ako 2 tyzdne
$checkdate = strtotime('-2 weeks');
$logger = new Promeo(':tp:logs');
foreach ($logs as $log) {
	if ($log->date < $checkdate) {
		$logger['d'] = $log->id;
	}
}
$logger->flushDelete();

Metoda flushDelete vracia pocet uspesne vymazanych zaznamov.

Sikovne vsak? Teraz vsak prichadza ta spravna chvila na odkrytie hlavnej prednosti Promea,
ktoru ja interne nazyvam „poskladaj ma ako chces“. Na tradicnom pristupe k tvorbe modelov
mi hodne vadila jedna vec, pokial som na jednom mieste aplikacie potreboval ziskat vsetky zaznamy
a na druhom zaznamy vyhovujuce urcitej podmienke vecsinou to znamenalo nadefinovat dve takmer totozne
metody, ktore sa lisili len v pridani podmienky. Samozrejme, niekoho by napadlo spravit obecnu funkciu, ktora
berie rozne argumenty urcujuce klauzulu where, order by, limit apod. To vsak ale znamena, ze pokial chcem
pouzit len limit musim si pamatat kolky parameter v poradi to je a ostatne nastavit na NULL – fuj fuj, nepekne riesenie.

Ovela viac ma preto pritahovala myslienka moct si nadefinovat model ad-hoc priamo na mieste kde ho potrebujem a
moct ho kedykolvek zmenit. Toto je zakladna a nosna myslienka celeho Promea – postav si model aky chces a najme tam
kde to realne potrebujes! Pozrime sa preto ako sa Promeo stavia k relaciam v databazach a ako s nimi pracuje.

V ponimani vztahov v databaze existuju v podstate tri modelove situacie:

1. Entita, ktora obsahuje ako svoju property kolekciu dalsich entit – napr. kurz (1) a terminy (n)
2. Entita, ktora obsahuje ako svoju property dalsiu entitu – napr. kurz (1) a miesto konania (1)
3. Entity, ktore obsahuju ako svoju property kolekciu inych entit – napr. novinky (n) a tagy (n) Rozdiel oproti prvemu pripadu bude v tom ako je relacia realizovana v databaze

Podme si teda rozobrat jednotlive pripady:

Moze byt toho viac

Majme tabulku courses:

• id
• name

a tabulku terms:

• id
• id_course
• max_people
• date

a chceme ziskat vsetky kurzy spolu s terminmi, pricom chceme len terminy kde sa moze prihlasit viac
ako 5 ludi a chceme ich mat zoradene podla datumu zostupne. Jednoduchy ukol, no predpokladam, ze vela z
vas by to riesila rozne a podla mna miestami aj zbytocne komplikovane. Ja rad jednoduchost:

$courses = new Promeo('courses');
$courses->many('terms')
			->where('[max_people] > 5')
			->orderBy('date')->desc();

Tada! Vo vysledku dostaneme entitu, ktora bude mat ako property terms kolekciu terminov, ktore su zoradene podla
datumu a splnuju podmienku v klauzuli where. Mozno sa pytate ako Promeo vie odkial ma co brat, co su PK apod. Ano priznavam
toto je trosku modelovy priklad, kde je vyuzita sila konvencii a preto nebolo treba udavat nic viac (v opacnom pripade by
sa upresnila len druha tabulka a referencny kluc). Ku konvenciam sa
vsak dostanem za chvilu.

Mam len jedneho kamarata

Poupravme teraz trochu nas priklad. Uvazme, ze kazdy termin moze ucit iny lektor a my chceme mat
pri kazdom termine aj konkretne informacie o lektorovi.

Tabulka terms bude teda vyzerat nasledovne:

• id
• id_course
• max_people
• date
• id_teacher

a tabulka teachers:

• id
• name
• qualification

a nove zadanie pomocou Promea:

$courses = new Promeo('courses');
$courses->many('terms')
			->where('[max_people] > 5')
			->orderBy('date')->desc()
				->one('teacher');

Vo vysledku ma teraz kazdy termin property teacher, ktory obsahuje dane informacie o lektorovi.

Kazdy s kazdym paktuje

Posledny pripad je podobny tomu prvemu, lisi sa vsak v tom, ze relaciu sprostredkuva tzn. relation table:

Tabulka news:

• id
• published
• approved
• text

Tabulka tags:

• id
• tag

Tabulka news_have_tags:

• id_new
• id_tag

Vo vysledku chceme vsetky odsuhlasene novinky zoradene podla datumu publikovania zostupne spolu s relevantnymi tagmi.

$news = new Promeo('news');
$news->where('[approved] = 1')
	 ->orderBy('published')->desc()
	 	->relation('tags');

To je vsetko, naozaj. Zase raz sme sice vyuzili silu konvencii avsak samozrejme je mozne upresnit nazvy klucov v tabulkach a zdrojove tabulky.
Kazda novinka bude teda obsahovat ako property tags zoznam pridelenych tagov.

Zatiaľ len letmo som to prešiel a nevidím jednu vec – fetchPairs. Ako plníš selectboxy? Keď to bude niekde(ideálne na GitHube live) veľmi rád to otestujem.

A já jsem si o sobě myslel, že jsem grafoman :)

Co mi vadí, nebo mi to nepříjde úplně vhodné:

1) výpis dat entity

$user->name; // objektovy pristup
$user['email']; // array pristup

tohle je zbytečné, lepší je povolit jen jeden způsob (já raději objektový). Jde o to že nebudeš mást uživatele, zavedeš konvenci a oni se jí budou muset držet. Tohle jsem často taky řešil a zjistil jsem, že méně je někdy více. Když nebudeš mást uživatele 10 způsoby zápisu, věř mi že to ocení.

2) když css tak css

$relations = new Promeo(':tp:user_relations', '#uid_1,uid_2');

tohle by ti v CSS neprošlo

$relations = new Promeo(':tp:user_relations', '#uid_1,#uid_2');

tohle ano

$relations = new Promeo(':tp:user_relations', array('#uid_1','#uid_2')); // popř. array('uid_1','uid_2')

a takhle by se mi to líbilo nejvíc :)

3) CRUD – hromadné vytváření

$vouchers[] = $voucher;
$vouchers->add($voucher, FALSE);
$vouchers['a'] = $voucher;
$vouchers['+'] = $voucher;

tohle je vskutku odstrašující, nechal bych maximálně první 2

4) flush

$vouchers->flushAdd();

tohle je myslím zbytečně matoucí, to máš jako metodu na každou ze 4 operací?

$vouchers->flush();

tohle mi příjde jednodužší

pokud však trváš na tvém crud přístupu, tohle bude pořád lepší (máš hromadné splachovadlo)

$vouchers->flush('u');
$vouchers->flush('update');

5) CRUD všeobecně

Když na to tak koukám, ono to skoro vypadá že máš vždycky v objektu Promeo 4×UnitOfWork. Což není moc košér
Víc by se mi líbila fronta jako má Doctrine2. Něco si o tom přečti, třeba tě něco napadne ;)

6) CRUD – hromadné operace

co mi vyloženě vadí, tak jak to pracuje s těmi ID. Ty si dáš do fronty, ty jednotlivé idčka entity a pak to pravděpodobně mažeš pomocí nějakého DELETE FROM .. WHERE id IN(...). Nebylo by lepší něco takového?

foreach ()
$checkdate = strtotime('-2 weeks');
$logger = new Promeo(':tp:logs');
foreach ($logs as $log) {
        if ($log->date < $checkdate) {
                $logger['d'] = $log;
        }
}
$logger->flushDelete();

s tím, že by jsi si v Promeo sám podle primárních klíčů vytáhl property, podle které by se mazalo? usnadnilo by to zápis pokud máš více primárních klíčů

7) math

$users->math(6, 'salary*2; hours+20; holiday-10');

v toggle to máš ale hezčí!

$users->math(6, array('salary*2', 'hours+20', 'holiday-10'));

8) hromadné cokoli

$vouchers = new Promeo(':tp:vouchers');
// predpokladajme, ze mame v premennej $oldVouchers entity starych
// voucherov, ktore chceme invalidovat
foreach ($oldVouchers as $id => $foo) {
        $vouchers['t'] = $id;
}
$vouchers->toggleColumns('valid', 'editable'); // nastavime, ktore stlpce sa maju znegovat
$vouchers->flushToggle();

nápad: co takhle použít výsledky, místo zbírání IDček?

$vouchers = new Promeo(':tp:vouchers');
$result = $vouchers->select('id')->getAll();
$vouchers->toggle($result, array('valid', 'editable'));

to vypadá lépe, né? :)

9) získávání záznamů

$relations = new Promeo(':tp:user_relations', '#uid_1,uid_2');
$relation  = $relations[array('uid_1' => 1, 'uid_2' => 2)]; // vztah s klucom (1,2)

když pominu fakt, že tohle jsem ještě nikde neviděl a moc se mi to nelíbí (ale asi bych si zvykl) tak bych ti poradil, co takhle to ještě víc ulehčit?

$relations = new Promeo(':tp:user_relations', '#uid_1,uid_2');
$relation  = $relations[array(1, 2)]; // vztah s klucom (1,2)

stejně klíče máš pojmenované, a pokud nepotřebuješ měnit jejich pořadí, tak takhle je to více přehledné.

10) WTF nedefinované proměnné?

while ($relations->walk($pk, $relation, $iterator)) { }

ale fuj

while (list($pk, $relation, $iterator) = $relations->walk()) { }

http://cz.php.net/list http://cz.php.net/each ;)

11) Statická třída?

PromeoSettings::$convention = 'MyConventionClass';
PromeoSettings::$entityType = 'MyEntityClass';

tohle je fuj fuj

12) Nějaký ten hromadný obal?

Líbilo by se mi něco takového

class Database
{

	private $configurator;

	private $tables = array();


	public function table()
	{
		$args = func_get_args();
		$key = serialize($args);

		if (!isset($this->tables[$key])) {
			$ref = new ReflectionClass('Promeo');
			$table = $ref->newInstanceArgs($args);
			$table->setConfigurator($this->configurator);
			$this->tables[$key] = $table;
		}

		return $this->tables[$key];
	}

	public static function createDatabase($options)
	{
		$configurator = $options['configurator'] ?: 'PromeoConfigurator';
		$db = new static(new $configurator());
		return $db;
	}
}

service.database.factory = Promeo\Database::createDatabase()

$db = $application->getService('database');
$vouchers = $db->table(':tp:vouchers');
....

s tím, že tohle by se zase dalo hezky zabalit do pár metod třeba v presenteru, nebo v nějakých službách atd, ale tak to už je kosmetika :)

Závěrem

Syntaxe na relace se mi velice líbí, něco podobného jsem se snažil vymyslet a tvoje synataxe je dovedená k dokonalosti :)

Jinak přeju zdařilý vývoj a spoustu spokojených uživatelů. Doufám, že moje reakce přinesla nové nápady :)

Editoval HosipLan (24. 12. 2010 20:33)

westrem napsal(a):

V ponimani vztahov v databaze existuju v podstate tri modelove situacie:

1. Entita, ktora obsahuje ako svoju property kolekciu dalsich entit – napr. kurz (1) a terminy (n)
2. Entita, ktora obsahuje ako svoju property dalsiu entitu – napr. kurz (1) a miesto konania (1)
3. Entity, ktore obsahuju ako svoju property kolekciu inych entit – napr. novinky (n) a tagy (n) Rozdiel oproti prvemu pripadu bude v tom ako je relacia realizovana v databaze

Môžeš uviesť na ukážku aj dotazy, ktoré by sa pri jednotlivých vzťahoch vykonali?

Editoval dakota (25. 12. 2010 9:17)

Zdá se mi to jako produkt životaschopný. Určitě se na to podívám podrobněji. A ovládání je mi velice sympatické. Ale těch více metod na přidávání mi přijde zvláštní. Array i objekt přístup je zbytečný, ale z JavaScriptu jsem zvyklý, že to je to samé, takže za mě ok. ;)

Fakt se mi to moc líbí. (po přečtení úvodu zde na fóru)

JAM3SoN

Kedze cely Promeo je stavany na principe prace s low level entitami (s moznostou definovat si vlastne), nema separatne metody typu fetchSingle, fetchPairs apod. ako ich pozname napr z dibi. Fetch pairs a jej funkcionalita je vsak hojne pouzivana, preto uvazujem o metode, ktora by vedela z daneho result setu vratit prave pole obsahujuce pozadovany kluc a value.

bojovyletoun

Ormion som nepouzival a ani nevidel zdrojaky. Vies mi priblizit co behaviours v jeho ponimani znamenaju?

HosipLan

V prvom rade velke dakujem, ze si sa tak rozpisal ;).

Rozne pristupy

Zatial tam ponecham oba s tym, ze preferovany bude objektovy. Nie vsetci vsak vedia ako dynamicky pristupovat k objektovym properties a pre tychto ludi bude lepsie pouzivat array access syntax. Beriem vsak poznamku o tom, ze menej je niekedy viac, s tym sa neda nez suhlasit.

Vlastne ID u entity a CSS

Ako pisem, je to len ispiracia v pouzity znaku, nie v uplnej syntaxi. Ja viem, ze v CSS by moj zapis nepresiel, resp. neznamenal to co znamena u mna. To vsak nebol ani zamer.

CRUD a hromadne metody

S tymi roznymi sposobmi ako pridavat entity na zasobnik mas pravdu. Je to viac ci menej moja lenivost a preto si umoznujem viac sposobov, ale skor sa asi uchylim k standardizacii jedneho a od zvysnych upustim.

Samostatne flush metody vsak ponecham, z toho dovodu aby bolo mozne flushovat jednotlive zasobniky separatne. Pridam vsak asi jednoduchu flush metodu, ktora bude flushovat ten zasobnik s ktorym sa naposledy robilo.

UnitOfWork – priznam sa, ze ten pojem pocujem prvykrat. Je to nejaky design pattern? (Tie mam cca prestudovane ale tento nazov som nikde nevidel). Vies mi to popisat blizsie, pripadne ma odkazat na nejaky dobry zdroj? Vdaka

Hromadny DELETE – ano tu mas pravdu, sam teraz premyslam, preco som to implementoval tak, ze musi user rucne udavat IDcka ked to moze Mapper spravit zanho, vdaka za vypichnutie ;)

Ziskavanie zaznamov

Co sa viac stlpcovych ID tyka, chcem ten sposob zapisu sprehladnit a zjednodusit. Tak ako som to napisal to tam je preto aby bolo jasne, ze je to mozne, chcem to vsak dotiahnut na vyssi level intuitivnosti.

Nedefinovane premenne

Vidis v tom pristupe vyslovene nieco spatne? Nie je to tradicny pristup ale nemyslim si, ze je zly. list samozrejme poznam, ale osobne sa mi jeho pouzivanie nepaci a tiez sa mi nepozdava myslienka, ze by mala metoda walk vracat pole, odhliadnuc od toho, ze moj zapis je kratsi a podla mna aj zrozumitelnejsi.

Staticka trieda

Zase raz, nevidim v tom nejak extra problem. Ano, nie je to koser z OOP hladiska, cisto staticke triedy vyuzivam minimalne, ale nastavenie zatial spociva iba z tychto dvoch veci, preto nevidim momentalne dovod to menit. Naviac dalsi argument, preco je to zatial takto je ten, ze tak torchu cakam ako sa vyvinie DI v Nette a aka bude jeho finalna podoba a podla toho by som to v buducnosti upravil.

Hromadny obal

Vyzera pekna, ale ako pisem vyssie, service like to spravim vo chvili ked bude jasne DI v Nette.

westrem napsal(a):

Rozne pristupy

Nie vsetci vsak vedia ako dynamicky pristupovat k objektovym properties…

Však to můžeš pak vysvětlit v dokumentaci a nechta jen jeden přístup :)

Vlastne ID u entity a CSS

Ako pisem, je to len ispiracia v pouzity znaku, nie v uplnej syntaxi.

nejde mi o to aby to v CSS prošlo, ale aby to bylo intuitivnější :)

CRUD a hromadne metody

UnitOfWork

je to Design Patter, v podstatě obálka, do které se ukládají změny a pak se hromadně spustí jejich persistence. V režii UoW je ale pouze to ukládání změn, ta persitence je pak v režii některé jiné třídy.

Nedefinovane premenne

Vidis v tom pristupe vyslovene nieco spatne? Nie je to tradicny pristup ale nemyslim si, ze je zly. list samozrejme poznam, ale osobne sa mi jeho pouzivanie nepaci a tiez sa mi nepozdava myslienka, ze by mala metoda walk vracat pole, odhliadnuc od toho, ze moj zapis je kratsi a podla mna aj zrozumitelnejsi.

je to ošklivá syntax

foreach ($relations->walk() as $pk => $entity){
	// ...
}

foreach ($iterator = new PromeoWalkIterator($relations) as $pk => $entity){
	// ...
}

Nehledě na to že ten iterátor je jenom třešnička a využiješ ho tak ve 20% případů (z toho ještě většinou jen v šabloně) tak je zbytečné ho tam cpát.

Staticka trieda

Zase raz, nevidim v tom nejak extra problem.

Statické třídy jsou zlo. Protože pak se rozhodnu, že potřebuju pracovat s více databázemi a ta jedna bude mít jinou konfiguraci? Jsem kde? :)

Nevidíš důvod to měnit protože se ti nechce, ale sám moc dobře víš, že by to tak bylo lepší :)

Hromadny obal

Vyzera pekna, ale ako pisem vyssie, service like to spravim vo chvili ked bude jasne DI v Nette.

Na Nette DI se vykašli, nepotřebuješ nástroje Nette, aby jsi mohl používat DI. Je to návrhová vzor né knihovna

Editoval HosipLan (14. 1. 2011 8:57)

HosipLan napsal(a):

Syntaxe na relace se mi velice líbí, něco podobného jsem se snažil vymyslet a tvoje synataxe je dovedená k dokonalosti :)

No a není lepší syntaxe NotORM, kdy připojované tabulky v dotazu vůbec nemusím psát a prostě je jen používám ve výsledku? Nejde o žádný sarkasmus – ptám se vážně, jestli jsem něco nepřehlédl.

Mě zaujala práce s vícesloupcovým primárním klíčem – to převezmu do NotORM.

Vypadá to luxusně, kdypak se lze těšit na zveřejnění?

Jeden tip k referal key id_course: Jakub v NotORM zvolil opačný (course_id) a tuším, že to má podpořené anketou mezi vývojáři. I když to bude v Promeu nastavitelné, většina vývojářů bude nastavovat právě tento parametr. Nestálo by za to udělat Jakubovo konvenci jako výchozí?