Lean Mapper – tenké ORM nad dibi

Jestli mi dnes v Lean Mapperu osobně něco opravdu chybí, tak je to možnost namapovat výsledek nějakého komplexnějšího SQL dotazu na inicializovaný strom entit. Něco, co například v Doctrine krásně řeší DQL (položení dotazu a následná hydratace entit).

Ukažme si na triviálním zadání, o co vlastně jde: vypište autory knih, kteří napsali knihy s průměrným hodnocením lepším než tři hvězdičky, a pro každého z těch autorů vypište všechny takové knihy.

Prvním možným řešením je vybrat autory, inner-joinout si jejich knihy, vzniklou relaci omezit podle požadovaného hodnocení knih a pro optimalizaci přenášených dat lze autory sloučit pomocí GROUP BY. Během vypisování autorů je pak zapotřebí při traverzování na knihy opět vyfiltrovat ty s požadovaným hodnocením.

Druhým možným řešením je vybrat autory a relevantní knihy najednou v rámci jednoho dotazu. Opět bude obsahovat inner join a omezení podle požadovaného hodnocení knih.

Každé z výše uvedených řešní má své výhody a nevýhody. Slabinou prvního řešení je to, že se musí dvakrát filtrovat hodnocení knih. Na druhou stranu se nepřenáší redundandní data. A přesně opačně je pak na tom druhé řešení. Knihy se filtrují pouze jednou, ale ve výsledku se zase přenášejí redundandní data. Klasika. :)

První přístup je sice často výhodnější, ale zejména při joinu většího množství tabulek s košatými restrikcemi je trochu neohrabaný a také ztrácí na efektivitě.

Lean Mapper, inspirovaný NotORMem, doteď podporovat pouze první zmíněný přístup, ale to změnil tento nenápadný commit. Od tohoto commitu lze výsledek jakéhokoliv SQL dotazu „hydratovat“ na inicializovaný strom entit, takže už nic nestojí v cestě k používání druhého přístupu.

Již teď je k vidění v testech ukázka takové „dřevařské hydratace“. Jak vidno, zatím je to záležitost dost krkolomná, ale to se velmi brzy změní. Nic nebrání implementaci nadstavby, která všechnu tu dřevařskou práci udělá za nás. My, koncoví programátoři, to jen budeme dirigovat nějakým LQL:

$query = $queryHelper->createDomainQuery();

$query->select('a, b')
    ->from(Author::class, 'a')
    ->join('a.books', 'b')
    ->where('b.rating >= ?', 3);

$authors = $query->getResult();

foreach ($authors as $author) {
    echo "$author->name\n;"
    foreach ($author->books as $book) {
        echo "- $book->name\n";
    }
}

Databázi se položí jeden jediný dotaz.

Celé takové LQL bych rozvíjel v separátním repositáři jako nadstavbu nad Lean Mapperem, kterou lze volitelně použít. Chtěl bych, aby tak vzniklo nějaké výsledné best practice pro modely využívajících Lean Mapper. Má představa je, že takové řešení bude mít tři vrstvy:

1) Sadu nástrojů pro vyloženě ruční hydratování výsledku nějakého SQL a také pro sestavení takového dotazu. Půjde o ekvivalent mapování výsledku nativního SQL na entity v Doctrine
2) LQL jako nadstavbu nad tím, která bude sice o něco omezenější, ale zase bude extrémně pohodlná na používání. Půjde o ekvivalen DQL, HQL, prostě o další OQL
3) Základ pro Query objekty, které by se překládaly právě do LQL. Půjde víceméně o ekvivalent Query objektů z Kdyby\Doctrine

Myslím, že to celé bude pro Lean Mapper zase obrovský krok dopředu.

Maximálně vítám vaše názory, nápady, rady… Můžeme to řešit buďto zde, anebo v této issue na GitHubu. Díky!

Editoval Tharos (28. 5. 2014 16:19)

Ahoj,
prosím Vás, zajímalo by mě, jak můžu pomocí LM elegantně udělat tento use-case:
Mám entitu Question a kažná má kolekci Vote – hlasů, kde hlas má Value, což je hodnota +1/-1.
Jak elegantně spočítat skóre?

Pokoušel jsem o něco, ale nikam to nevedlo :/

/**
 * Description of Question
 *
 * @property string $title
 * @property string $text
 * @property User $author m:hasOne
 * @property Answer[] $answers m:belongsToMany
 * @property Tag[] $tags m:hasMany
 * @property Vote[] $votes m:belongsToMany
 * @property-read int $score
 */
class Question extends BusinessEntity
{
    public function getScore()
    {
        return $this->getValueByPropertyWithRelationship('votes', new \LeanMapper\Filtering(function (\LeanMapper\Fluent $statement) {
            $statement->select('sum(value)');
        }));
    }
}

Ahoj přátelé,

tak jsem dnes vydal verzi 2.2.0. Zde jsou nějaké užitečné odkazy:

• API dokumentace online
• Předpřipravený balíček ke stažení

Z novinek (kterých je relativně málo) bych rád vyzdvihl následující:

• Zachovávání kolekce ID ve Fluent
• Nová metoda Connection::hasFilter
• Nově se lze odkazovat na aliasy v SQL (viz praktická ukázka)
• „Preloading“, který umožňuje vznik nadstavby zvané LQL

Podrobný přehled změn viz diff na GitHubu.

Zajímavé je, že změny neobsahují asi žádný BC break, takže aktualizace knihovny je vřele doporučovaná.

Dobrou zprávou budiž, že se trochu hýbe dokumentace. :) Zrovna dnes přibyly další části stránky věnované entitám.

Nadále platí, že dokud nebude dokumentace dokončená, snažím se aktivně zodpovídat všechny dotazy v issues na GitHubu a také jsem k dispozici na Skype jako v.kohout. Nebojte se mě prudit :). Tím, že Lean Mapper používáte, mu děláte velkou službu.

Na závěr napíšu jedno takové malé zamyšlení… Zhruba od ledna tohoto roku jsem díky projektu, na kterém jsem se začal podílet, de facto denně ve styku nejen s Lean Mapperem, ale i s Doctrine 2. Umožnilo mi to poznat Doctrine mnohem hlouběji, než jsem ji znal, a vidět tak, jak si obě knihovny vedou vedle sebe. Tato zkušenost mě znovu utvrdila v tom, že Lean Mapper má smysl, že je k Doctrine „důstojnou příbuznou“ a výbornou alternativou v mnoha případech. Za úplně nejlepší považuji umět pracovat s oběma těmito ORM a podle konkrétní aplikace se rozhodovat, kterou použít. V podstatě tedy vylučuji, že by se z mé strany z Lean Mapperu stala „dále neudržovaná knihovna“ bez podpory a budoucnosti.

Nyní se chci zaměřit na další rozvoj dokumentace (vím, že je to evergreen) a také na nadstavbu Lean Query, která, až bude hotová, přinese z mého pohledu obrovský posun v tom, jak elegantní budou vaše modely nad Lean Mapperem moci být.

Díky za přízeň!

Editoval Tharos (28. 4. 2014 1:50)

@Mesiah: To zní zajímavě. :)

Vyzkoušel bys prosím, co na tom testovacím serveru vypíše následující skript?

$reflection = new ReflectionClass('Model\Entity\User');
var_dump($reflection->getDocComment());

Ahoj,

nejprve bych chtěl poděkovat za povedenou knihovnu. LeanMapper se nyní pokouším implementovat do jednoho projektu. Při použití filtrů jsem narazil na dle mého vcelku nestandardní chování a nevím, zda je to chyba na mé straně či na straně LM. Pokusím se problém popsat.

Moje aplikace
Mám entitu Event a v ní property EventTerm[] m:belongToMany(). Potřeboval bych EventTerm[] seřadit a limitovat.

Entita

/**
 * @property int $id
 * ...
 * @property EventTerm[] $term m:belongsToMany(#union) m:filter(order,limit)
 * ...
 */

class Eventextends Entity
{
}

Filtr

class DefaultFilter
{
    public static function limit(\LeanMapper\Fluent $statement, $args = null)
    {
        if(!empty($args['limit'])){
            $statement->limit($args['limit']);
        }
    }

    public static function order(\LeanMapper\Fluent $statement, $args = null)
    {
        if(is_array($args) and !empty($args['order'])){
            $statement->orderBy($args['order']);
        }
    }

}

Presenter

foreach ($eventRepository->findAll() as $event) {
    $filter = array('limit' => 5, 'order' => 'date_from ASC');
    foreach ($excursion->getTerm($filter) as $term) {
        var_dump($term->date_from);
    }
}

V tomto okamžiku se vše chová dle předpokladů Termíny jsou limitovány u každého eventu na maximálně 5 záznamů.

SQL dotaz vypadá takto:

(
SELECT `event_term`.*
FROM `event_term`
WHERE `event_term`.`event_id` = 8
ORDER BY date_from ASC
LIMIT 5)
UNION (
SELECT `event_term`.*
FROM `event_term`
WHERE `event_term`.`event_id` = 9
ORDER BY date_from ASC
LIMIT 5)
UNION (
SELECT `event_term`.*
FROM `event_term`
WHERE `event_term`.`event_id` = 13
ORDER BY date_from ASC
LIMIT 5)

Problém ale nastane v případě, že přidám jiný filtr, nebo pouze změním pořadí filtrů:

* @property EventTerm[] $term m:belongsToMany(#union) m:filter(limit,order)

V tomto případě je SQL dotaz následující a počet Termínu je limitovaný celkem na 5 záznamů, ale ne u každého záznamu, ale celkem.

(
SELECT `event_term`.*
FROM `event_term`
WHERE `event_term`.`event_id` = 8
ORDER BY date_from ASC)
UNION (
SELECT `event_term`.*
FROM `event_term`
WHERE `event_term`.`event_id` = 9
ORDER BY date_from ASC
LIMIT 5)
UNION (
SELECT `event_term`.*
FROM `event_term`
WHERE `event_term`.`event_id` = 13
ORDER BY date_from ASC
LIMIT 5)
LIMIT 5

Všimnul jsem si, že u prvního subselectu chybí limit, který je pak až úplně na konci.

Dále bych se chtěl zeptat, jak nejlépe vyřešit situaci, kdy bych chtěl v anotaci definovat defaultní řazení například:

m:filter(order#date_from ASC)

a následně mít možnost při výpisu, řazení změnit na jiné

$event->getTerm(array("order" => 'date_from DESC'))

ale takto se mi předá do filtru pouze argument uvedený v anotaci.

verze LeanMapperu 2.2.0

Editoval mirdič (17. 5. 2014 22:09)

Ahoj,

nadstavba Lean Query (také popsaná zde) se v posledních dnech výrazně posunula a již si s ní lze hrát.

Co aktuálně umí nejlépe ukazují testy, hlavně pak tento.

Za základní ukázku použití můžeme považovat například tohle:

$domainQuery->select('b')
        ->from(Book::class, 'b')
        ->join('b.author', 'a')->select('a')
        ->leftJoin('b.tags', 't')->select('t');

$books = $domainQuery->getEntities();

foreach ($books as $book) {
    echo "$book->name\r\n";
    echo "\tAuthor: {$book->author->name}\r\n";
    echo "\tTags:\r\n";
    foreach ($book->tags as $tag) {
        echo "\t\t$tag->name\r\n";
    }
}

Když tento kód spustíme nad tou SQLite databází, která se nachází v testech, vypíše se následující:

The Pragmatic Programmer
    Author: Andrew Hunt
    Tags:
        popular
        ebook
The Art of Computer Programming
    Author: Donald Knuth
    Tags:
Refactoring: Improving the Design of Existing Code
    Author: Martin Fowler
    Tags:
        ebook
Introduction to Algorithms
    Author: Thomas H. Cormen
    Tags:
        popular
UML Distilled
    Author: Martin Fowler
    Tags:

Pointou je, že se vykoná je jeden jediný dotaz (vypadá takto).

Asi jste si všimli, že takto se nám vybraly i ty knihy, které nejsou označeny žádnými tagy. Není problém změnit leftJoin na join:

$domainQuery = $domainQueryFactory->createQuery();

$domainQuery->select('b, a')
        ->from(Book::class, 'b')
        ->join('b.author', 'a')
        ->join('b.tags', 't');

$books = $domainQuery->getEntities();

foreach ($books as $book) {
    echo "$book->name\r\n";
    echo "\tAuthor: {$book->author->name}\r\n";
}

A rázem z toho máme výpis pouze těch knih, které mají nějaké tagy:

The Pragmatic Programmer
    Author: Andrew Hunt
Refactoring: Improving the Design of Existing Code
    Author: Martin Fowler
Introduction to Algorithms
    Author: Thomas H. Cormen

V této durhé ukázce jsme si také ukázali, že aliasy v SELECT části lze zapisovat hromadně a také, že lze v joinech pracovat s daty, které pak ale nejsou součástí SELECT, protože je pak třeba nemusíme vůbec chtít vypisovat. Položený SQL dotaz vypadá takto.

Dále bych vám chtěl ukázat tuto situaci:

$domainQuery = $domainQueryFactory->createQuery();

$domainQuery->from(Book::class, 'b')->select('b')
        ->join('b.author', 'a')
        ->join('b.tags', 't');

$books = $domainQuery->getEntities();

foreach ($books as $book) {
    echo "$book->name\r\n";
    echo "\tAuthor: {$book->author->name}\r\n";
    echo "\tTags:\r\n";
    foreach ($book->tags as $tag) {
        echo "\t\t$tag->name\r\n";
    }
}

Všimněte si, že pracujeme s daty z celkem čtyř tabulek, SELECT se odehrává jenom do jedné tabulky, ale při výpise pak ta ne-vyselektovaná data chceme vypsat. Lean Mapper (s Lean Query) si s tím poradí a potřebná data si efektivně donačte lazy způsobem tak, jak byste očekávali. Výstup bude opět následující:

The Pragmatic Programmer
    Author: Andrew Hunt
    Tags:
        popular
        ebook
Refactoring: Improving the Design of Existing Code
    Author: Martin Fowler
    Tags:
        ebook
Introduction to Algorithms
    Author: Thomas H. Cormen
    Tags:
        popular

S tím, že se položí tyto čtyři dotazy.

Zde si neodpustím drobné srovnání s Doktrínou, která by v takovémto případě už spadla do N+1 problému. Příjemné na Lean Mapperu je, že namísto do takového cyklického stylu kladení dotazů spadne do „NotORM stylu“.

Asi jste si všimli, že syntaxe je velmi podobná DQL (respektive Query Builderu v Doctrine). To je umělecký záměr, protože API Doctrine mi přijde zdařilé, intuitivní. Díky tomu vy, kteří máte zkušenosti s Doktrínou, asi budete Lean Query ihned chápat a umět používat.

Nadstavba je zatím trochu v plenkách, ale jelikož ji teď sám chci použít v jednom svém projektu, bude se velmi rychle vyvíjet. Roadmap na následující dny je cca následující:

• Doplnit WHERE klauzuli, se kterou to teprve bude plnit ten hlavní účel
• Zrefaktorovat vnitřní implementaci. Nyní je řada věcí na můj vkus až příliš array based, v plánu je dekompozice do menších objektů s jasným API

Mám z toho, jak Lean Query krystalizuje, osobně velkou radost. Ukazuje se, jak je Lean Mapper na takovouto nadstavbu perfekně připravený. Všimněte si třeba toho, že celý Lean Query je nyní „záležitost na pár řádků“.

Také se mi líbí obrovský potenciál a možnosti, jaké nabízí. Plánuji například povolit volitelně „obousměrný preloading“, kdy se vám zároveň zinicializuje vlastnící i inverzí strana relace (používám termíny z Doctrine, protože o lepších nevím). Takže budete moci například traverzovat z autorů zpátky na knihy, aniž by se položily nové dotazy databázi (pokud vám samozřejmě budou stačit data, která už jsou z databáze načtená). Tohle celé používat v modelech v kombinaci s nějakými hezkými Query Objekty bude radost!

Odhaduji, že v horizontu několika dní bude k dispozici nějaká RC verze s veškerou základní funkcionalitou. Další funkconalitu pak budu rád doplňovat podle potřeby – mé i dalších uživatelů. Ono vymyslet by se toho dala spousta a praxe nejlépe ukáže, co je jak důležité.

Enjoy!

Editoval Tharos (28. 5. 2014 15:12)

Inspirovaného knihovnou LeanMapperQuery mě napadla jedna taková neskutečně šikovná věc. Nebo alespoň doufám, že šikovná :). Představte si, že by šlo něco takového:

$authors = $authorRepository->findAll();

foreach ($authors as $author) {
    // ... print something from Author
    foreach ($author->findBooks(function (DomainQuery $query) {
        $query->where('this.name != %s', 'Lean Mapper Guide')
            ->leftJoin('this.tags', 't')
            ->where('t.name IN %in', ['ebook', 'printed']);
    }) as $book) {
        // ... print something from Book
        foreach ($book->tags as $tag) {
            // ... print something from Tag
        }
    }
}

Vykonají se celkem dva dotazy: první získá všechny autory, druhý získá všechny jejich knihy bez knihy Lean Mapper Guide a zároveň také všechny tagy těchto knih, které mají název buďto ebook nebo printed.

Při iteraci nad takovými tagy se už žádný další dotaz nepoloží.

V tomhle já osobně vidím neskutečně silnou zbraň. Umožňuje to začít mezi entitami traverzovat klasickým způsobem a až někde „v hloubi“, až se zjistí, že by se něco hodilo pre-loadnout, tak tak učinit.

Svým způsobem je to varianta na criteria matching v Doctrine, ale s tou obrovskou výhodou, že tady by šel udělat i JOIN dalších dat, která by se tím tak předpřipravila.

Editoval Tharos (2. 6. 2014 1:37)

Zdravim, zajimalo by me, jakym zpusobem prakticky resite nebo by jste resili mockovani entit? Prijde mi to pomerne problematicke, tim, ze jsou jejich vlastnosti definovany zpravidla pres anotace. Zatim me jako jedine „rozumne“ reseni napada jit cestou dedeni definovanych entit a prepsani veskerych properties na gettery/settery.

V soucasnosti mi tomuto brani pouze to, ze nepouzivam zadnou entity factory (pouzivam starou verzi LM).

Jde mi hlavne o to, ze bych se z duvodu komplexiti rad vyhnul nutnosti testovani na „zive“ DB.

Diky moc za nazory.

JR

@Tharos: Moc diky za nazornou ukazku, presne tohle jsem potreboval! Je to fakt parada, nevim, co presne za verzi dosud pouzivam, tusim nekdy z konce minuleho leta, nektere metody byly asi prejmenovany nebo pridany, kazdopadne to uz je muj problem. Delsi dobu uvazuji nad updatem knihovny, toto bude asi konecne ten pravy impulz :) Jeste jednou diky za perfektni nasmerovani, z nejakeho duvodu me nenapadlo, ze by to mohlo byt ve skutecnosti tak „primocare“.

Edit: Tak po aktualizaci knihovny na aktualni vyvojovou verzi uvedeny postup funguje bezvadne. Dalsim problemem, ktery me ceka, bude mockovani repositaru :)

Editoval JuniorJR (4. 6. 2014 23:28)

Včera večer jsem špatně mergnul jeden konflikt a mám dojem, jestli jsi zrovna náhodou netrefil na problém, který tím vznikl :).

Mohl bys, prosím, vyzkoušet aktuální develop teď z rána?

Dobře, že se to posunulo.

Stabilní by měla být verze v2.2.0 (je otagovaná). Dokonce koukám, že to testování entit bez databáze i včetně traverzování bude funkční už i v ní.

Pokud narazíš na nějaký bug v ní, otevři mi prosím issue…

Větev develop je stabilní po naprostou většinu času. Dost vzácně si tam vyrobím nějaký překlep nebo něco špatně mergnu (jako třeba včera).

Koncepčně se nic nezměnilo, nějakých hlubokých zásahů bys měl být ušetřen.

Vyzkoušel bys prosím tu verzi v2.2.0 a dal bys mi vědět? Díky!

JuniorJR napsal(a):

Tharos: Diky za promptni reakci :)
Soude dle kodu a chybove hlasky jsou ale podporovany pro vytvareni resultu pouze dibirow?

<?php
LeanMapper\Exception\InvalidArgumentException: Invalid type of data given, only DibiRow or array of DibiRow is supported at this moment.
in LeanMapper-master\LeanMapper\Result.php(96)
?>

Jo, to jsem zavedl až po commitu, který ale, zdá se, něco trochu rozbil :).

Stačí při tom ručním vytváření resultů nahradit [...] za new DibiRow([...]). Co nevidět ale bude fungovat zase i pouhé pole.

No jo, fakt jsem měl v develop větvi botu až hanba. :)

Už by vše mělo být fixnuté i v develop větvi. Pokud bys měl chuť, můžeš to vyzkoušet. Samozřejmě v té větvi už funguje to vytváření Result z polí.

Díky moc za pomoc při lazení :).

Přiznám se, že mě takový use case ještě asi nikdy nenapadl. :) To v té stable verzi funguje? Jak to vypadá v mapperu v metodě getPrimaryKey?

Ideálně to můžeme vyřešit v issues na GitHubu.

Editoval Tharos (5. 6. 2014 14:10)

Pri pokusu pristoupit k hodnote entity se polozi spatny dotaz do referencni tabulky, ve stable verzi mi to fungovalo. Asi to souvisi s tim, ze je to zaroven primarni klic.

@Tharos: Tak jsem vyzkousel aktualni dev verzi a vsechno, zda se, opet funguje. Neovlivnila tvoje posledni zmena i zpusob mazani entit?

Editoval JuniorJR (6. 6. 2014 22:13)

@Tharos: Ok, zatim vse funguje a zkousel jsem stable (2.2 tusim) a dev.

@medhi: UserRepository

Persistence by měla fungovat v pohodě, ale vytváření entit popř. kolekcí entit si musíš upravit (musíš explicitně určit, kterou entitu chceš použít viz API createEntity resp. createEntities ).

@Casper: Díky za vysvětlení, už mám svůj mapper. Měl bych ještě doplňují dotaz k propojovacím tabulkám, které s tím souvisí.

Mám používat jednu propojovací tabulku user__lesson nebo pro každtý typ usera extra tabulku

student__lesson a teacher__lesson?

Něco mi říká, že by to měl být user__lesson, ale co když pro různé typy userů potřebuju v propojovací tabulce různé parametry?

Díky moc

Ne, jen zavoláš ty metody s jiným parametrem…

// UserRepository

/**
 * find students
 */
public function findStudentsBy($conditions) {
    $rows = $query->where($conditions)->fetchAll();
    return $this->createEntities($rows, 'Student');
}

/**
 * find teachers
 */
public function findTeachersBy($conditions) {
    $rows = $query->where($conditions)->fetchAll();
    return $this->createEntities($rows, 'Teacher');
}

@medhi: Ahoj,

jak vypadá ta vazební tabulka? Je tedy nakonec jedna? Tipuji, že ano a při traverzování na $students se tedy děje následující:

1. Z databáze se přes tu vazební tabulku vytáhnout všechny potřebné řádky z tabulky user.
2. Pro každý řádek se pomocí mapperu určí, jestli je to Student nebo Teacher.
3. Vytvoří se z toho kolekce, která jde ven z té property.

No a tímto způsobem načteš mix studentů i učitelů, a proto ta „kontrola úplně nahoře“ vyhodí výjimku. Takhle bys totiž musel mít v té anotaci User[] $users. Pokud bys chtěl jenom studenty, je zapotřebí to traverzování přehnat přes filtr.

Potvrď mi, že je to tak (že máš jednu vazební tabulku s nějakým extra sloupcem), a já Ti klidně načrtnu řešení.

@medhi: Super, díky za přiblížení.

Automatické filtrování je strašně pohodlné. Nemusíš u všech vazeb, které vedou na konkrétní Student nebo Teacher, myslet na to, že je třeba do toho traverzování nějak zasáhnout. Proto Ti chci právě takové automatické řešení nastínit :). Dají se k tomu využít tzv. implicitní filtry v mapperu:

public function getImplicitFilters($entityClass, Caller $caller = null)
{
    if ($entityClass === Student::class) {
        return new ImplicitFilters(function (Fluent $statement) {
            $statement->where('[user.type] = %s', 'student');
        });
    }
    if ($entityClass === Teacher::class) {
        return new ImplicitFilters(function (Fluent $statement) {
            $statement->where('[user.type] = %s', 'teacher');
        });
    }
    return parent::getImplicitFilters($entityClass, $caller);
}

Pak se při každém traverzování na studenty nebo učitele z libovolné entity bude hlídat, aby ve výsledku byly správné entity.

Mimochodem, s těmi implicitními filtry pracují i repositáře. S výše uvedeným filtrem můžeš mít nejen UserRepository, kde si vytažení správných dat musíš hlídat sám, ale například i StudentRepository a TeacherRepository, ve kteréch se při zavolání protected metody createFluent ten filtr automaticky použije, takže už se o to taky nemusíš více starat.

Persistovat přes ty StudentRepository a TeacherRepository je také možné, stačí tam jen při vkládání do databáze vložit do low-level dat požadovanou hodnotu do sloupce type (v mém ukázkovém případě). Asi bych si na to přetížil metodu Repository::insertIntoDatabase… U persistence hodně záleží na tom, jak to celé spravuješ, jaký máš backend, jaké jsou případy užití atp. Je více možností, jak takové entity persistovat.

Kdyby Ti bylo cokoliv dalšího nejasného, klidně se ptej. :)

Editoval Tharos (17. 6. 2014 16:14)

Ahoj, chválím Lean Mapper, líbí se mi myšlenka i jeho zatím „snadné“ používání, teprve ho začínám začleňovat do projektu. Chtěl bych se ale zeptat, jakým způsobem řešíte napovídání v IDE, například ve spojení s Nette mám v presenteru:

$user = $this->userRepository->find(2);
$user-> ...

IDE neví, že v proměnné $user je instance App\Model\Entity\User. Dá se tam nějak dostat? Případně i do cyklu při použití findAll() a kdyby to šlo i do Latte šablon, tak to by bylo super :) – používám NetBeans.

@Tharos:

Tak to je super :) hlásím podporu i v NetBeans, minimálně v aktuální vývojové verzi. Teď už mi nebrání nic v používání.

Ahoj, rád bych se zeptal, jaký je best practice v následujícím případu:

Mám např. kategorie v eshopu a každá kategorie má několik produktů (1:N).

Nyní bych chtěl vypsat pouze ty kategorie a pouze ty produkty, kde je vyšší cena než 100,– Kč. Tzn. že se mi kategorie, kde budou všechny produkty s nižší cenou než 100,– nevypíšou a zároveň, u kategorie která má alespoň jeden produkt s cenou více jak 100,– se vypíšou pouze produkty, které tuto podmínku splňují.

Pokud si v repozitáři „Kategorie“ vytvořím metodu findHigherPrice($price)

public function findHigherPrice($price)
{
    $query = $this->connection->select('category.*')
            ->from('category')
            ->join('product')
                ->on('product.category_id = category.id')
            ->where('product.price > %i', $price);

    return $this->createEntities($query->fetchAll());
}

tak se mi vypíší pouze kategorie s alespoň jedním produktem se správnou cenou, ale zároveň se mi vypíší i produkty u dané kategorie, které podmínku nesplňují.

Jediné řešení, které mne napadá, je použití filtru u produktu při výpisu.

foreach($categoryRepository->findHigherPrice(100) as $category){
    $category->getProducts(100);
}

Otázka tedy zní: Existuje jiný způsob, abych nemusel filtrovat na dvou místech?