Nette\Database a hezčí podpora pro M:N vazby

Já bych se spokojil i s

$book->vyberMn('tag')->přesTabulku('book_tag') // názvy metod jsou ilustrativní

Troufám si říct, že můj návrh je hezčí :-) V ideálním světě (tedy v „Nette světě“ :-) ) by kodér neměl muset znát strukturu databáze. Můj návrh řeší také to, že by kodér ani nemusel používat v šablonách metodu related(), pokud programátor správně napíše model:

$authors = $database->table('author')
		->addShortcut('books', 'book')  // Database teď už ví, že `$author->books` má hledat přes `->related('book')->fetch()`

v šabloně

{foreach $author->books as $book}         // místo `$author->related('book')` napíše kodér jen `$author->books`
	{$book->title}: {$book->slogan} <br>
{/foreach}

A první věc, kterou jsou v tomto zkoušel bylo

$book->related('book_tag')->ref('tag')

ale tyhle metody jsou očividně dostupné jen na ActiveRow.

Tady nevím, jestli přesně chápu, co tím chceš říct. Nette\Database by si ony zkratky (shortcuty) ukládala do nějaké proměnné $shortcuts, kterou by pak měla k dispozici i ActiveRow.

paranoiq: Konvence ale nikdy nedokáže vyřešit problémy typu „sloupečky author_id a moderator_id ve stejné tabulce, oba odkazující na tabulku user“ apod.

Jinak s tebou ale souhlasím. Každopádně i za „rozumných“ konvencí by metoda addShortcut() měla smysl.

hrach: škoda.. Ale díky, těším se :-)

hrach: Jestli to chápu dobře, tak: V aplikaci nějak nastavím Nette\Database, aby místo ActiveRow vracela moji třídu (potomka Ndab\Entity). V tomto potomkovi si můžu překrýt metody pro vracení různých related záznamů.

To je určitě, co se týče objektového návrhu, skvěle vymyšlené řešení, ale nebude to zbytečně moc upsané? Pokud budu mít v DB dvacet tabulek, musím v projektu vytvořit dvacet nových tříd (potomků Ndab\Entity), abych v šabloně mohl používat hezký zápis?

hrach napsal(a):

To, že nemůžu Nette\Database říct, jaký objekt má vracet, je bohužel Davidův názor.

Jo, to mi naštvalo, když jsem myslel, že rozšířím ActiveRow o podporu m:n. Všude v kódu natvrdo new ActiveRow, nikde žádná IRowFactory :)

Jinak pokud to dobře chápu, tak ta tvoje nadstavba řeší prakticky jen něco jako setRowClass a podporu m:n relací?

Měnit třídu ActiveRow je balancování na hraně antipatternů. Každopádně v dev verzi je továrna function createRow().

Nepovažuji se za nějak zkušeného programátora, ale dovoluji si souhlasit s Hrachem.

Věřím, že tohle by ničemu v praxi nevadilo. O kterém antipatternu konkrétně tu mluvíme?

Znovu bych rád otevřel tohle téma. Zrovna jsem dokončil jeden projekt, kde jsem používal NetteDB a chvílemi mi práci spíš přidělávala, než ulehčovala. Přitom je ale v NetteDB geniální nápad a rád bych ji pomohl dostat do stavu, kdy se bude krásně používat za všech okolností. Zároveň jsem zjistil, že je potřeba daleko silnější API, než původní nápad s addShortcut().

Příklad: Chtějme vypsat seznam článků, a k nim seznam tagů. Pokud v modelu použijeme return $db->table('article'), tak na kodéra čeká škaredá práce s ->related():

{foreach $articles as $article}
  <h2>{$article->title}</h2>
  Tagy: {foreach $article->related('article_tag') as $article_tag}{$article_tag->tag->name}, {/foreach}
{/foreach}

Co když budeme chtít zobrazit jen aktivní tagy (v tabulce tag mějme sloupeček active s hodnotami 0, nebo 1):

{foreach $articles as $article}
  <h2>{$article->title}</h2>
  Tagy: {foreach $article->related('article_tag')->where('tag.active = ?', 1) as $article_tag}{$article_tag->tag->name}, {/foreach}
{/foreach}

A teď si představte, že tagů bude u každého článku moc, a tak budeme chtít zobrazit jen ty, které zpětně obsahují nejvíce článků. Zkuste si to napsat. Tohle už je programování v šabloně…

Hrachovo řešení

Taky bych se rád vyjádřil k Hrachovu řešení. Na nedávné přednášce David vyslovil myšlenku, že NetteDB má sloužit pro případy, kdy nechceme použít ORM. Ta myšlenka se mi opravdu líbí. Tím, že se ale Hrach snaží pro řádky každé z tabulek v DB psát vlastní třídu, z toho ORM vlastně dělá. Jeho nápad je objektový (tzn člověk se šíleně moc upíše) a podle výše zmíněné Davidovy (i mojí) myšlenky si myslím, že je to non-nette-db-way :-)

Jak bych si tedy představoval hezké řešení já?

Celá myšlenka stojí na tom, že každý Table\Selection by měl instanci svých vlastních konvencí (což je logické, protože každá tabulka má jiné cizí klíče). Tyto „nádstavbové“ konvence by jen rozšiřovaly klasické DiscoveredReflection a ConventionalReflection (které by v NetteDB samozřejmé zůstaly), a programátor by měl možnost tyto nádstavbové konvence upravovat.

Celé by to mohlo být zabalené např do takovéhohle API:

# V modelu

// Vybereme všechny články
$articles = $db->table('article');

// Hrátky s vlastními konvencemi
$aConv = $articles->getConventions();
$aConv->addColumn('tags', 'article_tag:tag');  // řekneme databázi, kde má hledat tagy

$aConv['tags']->where('active', 1);  // v šabloně chceme zobrazovat jen aktivní tagy

# V šabloně
{foreach $articles as $article}
  <h2>{$article->title}</h2>
  Tagy: {foreach $article->tags as $tag}{$tag->name}, {/foreach}
{/foreach}

Rád bych se o tom pobavil taky zítra na Poslední sobotě.

Sry, asi jsem to napsal fakt špatně. Prostě se mi nechce pro každou tabulku v DB vytvářet další vlastní třídu, pokud můžu čistotu kódu udržet i bez toho. Samozřejmě jsem pro, ať je řešení tohohle problému správně objektově navrhnuté – ale ať je to řešené uvnitř frameworku, a ne ať je programátor nucen vytvářet pořád další třídy a soubory.

Moje API (které jsem si ale vycucal z prstu dneska během asi desíti minut), by se určitě dalo napsat líp. Přesto se mi ale líbí a vlastně se stejný přístup v Nette už používá.

Pro srovnání:

$form->addText('name')
	->getControlPrototype()->addClass('foo');

$db->table('article')
	->getConventions()->addColumn('tags', 'article_tag:tag');

Protože pro každý Selection, který si vytáhnu z DB, můžou platit jiné konvence (nebo si to nazveme jinak, třeba „pohled na data“, pokud chceš).

Příklad: Pokud si vytáhnu články, bude platit konvence, že tagy se získávají přes tabulku article_tag:tag. Naproti tomu zboží z e-shopu (např. tabulka item) může mít taky tagy, ale dostaneš se k nim přes item_shop_tag:shop_tag. Navíc můžu chtít uživatelům zobrazit jen aktivní tagy, ale v administraci chci zobrazit (z nějakého důvodu) všechny tagy. Takže jednoduše řeknu, že pro uživatele platí konvence ->where('active', 1) a pro admina ne.

# V ArticleModelu
public function getArticles() {
	$articles = $this->db->table('article');

	$articles->getConventions()
		->addColumn('tags', 'article_tag:tag')->where('tag.active', 1);

	return $articles;
}

# V AdminModule\ArticleModel
public function getArticles() {
	$articles = $this->db->table('article');

	$articles->getConventions()
		->addColumn('tags', 'article_tag:tag');

	return $articles;
}

• article->related('article_tags:tag') byl návrh api…
• neni to o nic vic zavisle na konvencich nez normalni related.

Připravil jsem experimentální implementaci této funkce. Jako základ jsem použil implementaci od @juzna, doplnil implementaci insert a delete, připsal testy a provedl rebase na aktuální master.

Nevím si moc rady s podporou agregací takže to hází NotImplementedException. Rád bych kdyby se na to podíval někdo další.

Jestli to dobře chápu, tak se ti nelíbí tohle. Raději tedy vycházet rovnou z tabulky tags s backjoinem na tabulku book_tags?

Jak to vypadá s vývojem hezčí podpory M:N vazeb? Nemůžu nikde najít, jak to nakonec dopadlo.

Editoval Climber007 (3. 2. 2013 0:23)