Lean Mapper – tenké ORM nad dibi

Kešování se dá řešit i jen na úrovni šablon, takže bys nekešoval dotazy, ale až výsledná a už zpracovaná data.
Co je spousta lidí? Kolik za minutu a očekáváš nějaké koncentrace v určitých časech? (Např. sázkový systém je extrémně vytížený hodinu po skončení zápasu, tam má smysl kešovat hodně.)

Invalidaci dat udelas klasicky pres tagy: https://doc.nette.org/cs/2.4/caching#…

$templateCache = \Nette\Environment::getCache('Nette.Template.Cache');
$templateCache->clean(array(Cache::TAGS => $tags));

kudlajz napsal(a):

pokud ti jen o to snížit počet dotazů do db tak si teoreticky takovou cache můžeš napsat sám, v podstatě jen potřebuješ nějakou Dictionary, kde klíč může být složenina názevEntity-ID a hodnota samotná entita. Pokud entitu v dictionary nenajdeš, tak ji dočteš a vložíš.
Zajímavější ale budou dotazy kde je klauzuje where whatever in (1, 2, 3) tady je už je více strategií jak se zachovat. :)

Editoval Mesiah (27. 12. 2013 18:42)

Změň to to z: @property User $reviewer|NULL m:hasOne(reviewer_id)
na tohle: @property User|NULL $reviewer m:hasOne(reviewer_id)

Null je typ (Objekt uživatel, nebo null), ne název. To samé máš u těch intů, ale tam ti to nespadne na výjimku, jen se přetypuje na 0.

Ahoj, pokusil jsem napsat „něco jako Query Object“, který by mi vyhovoval při práci s repozitáři. Zajímaly by mě vaše názory a podněty.

LeanMapperQuery (GitHub)

Je to inspirováno „backjoin“ z NDB (NotORM). Přistoupím k ukázkám použití:

Mějme následující následující repozitáře (schéma databáze převzato z quickstartu LeanMapperu):

abstract class BaseRepository extends \LeanMapper\Repository implements IQueryable
{

    /**
     * @implements IQueryable
     */
    public function createFluent()
    {
        return parent::createFluent();
    }

    /**
     * @implements IQueryable
     */
    public function getTable()
    {
        return parent::getTable();
    }

    public function query()
    {
        return new BaseQuery($this, $this->mapper);
    }

    public function find(IQuery $query)
    {
        return $this->createEntities($query->createQuery());
    }

}

class AuthorRepository extends BaseRepository
{

}

class BookRepository extends BaseRepository
{

}

a entity:

class BaseEntity extends \LeanMapper\Entity
{

}

/**
 * @property int $id
 * @property string $name
 */
class Tag extends BaseEntity
{
}

/**
 * @property int $id
 * @property string $name
 */
abstract class Person extends BaseEntity
{
}

/**
 * @property Book[] $books m:belongsToMany
 * @property Book[] $reviewedBooks m:belongsToMany(reviewer_id)
 * @property string|null $web
 */
class Author extends Person
{

}

/**
 * @property int $id
 * @property Author $author m:hasOne
 * @property Author|null $reviewer m:hasOne(reviewer_id)
 * @property Borrowing[] $borrowings m:belongsToMany
 * @property Tag[] $tags m:hasMany
 * @property string $pubdate
 * @property string $name
 * @property string|null $description
 * @property string|null $website
 * @property bool $available
 */
class Book extends BaseEntity

}

Dále si nadefinujeme BaseQuery objekt:

class BaseQuery extends Query
{
    public function find()
    {
        return $this->sourceRepository->find($this);
    }
}

Pro znázornění spolupráce s implicitními filtry ještě uvedu Mapper:

class Mapper extends DefaultMapper
{
    public function getImplicitFilters($entityClass, Caller $caller = NULL)
    {
        if ($entityClass === "$this->defaultEntityNamespace\\Book") {
            return new \LeanMapper\ImplicitFilters(function (\LeanMapper\Fluent $statement) {
                $statement->where('[available] = 1');
            });
        }
        return array();
    }
}

Poté můžeme pracovat s repozitáři následujícím způsobem:

$bookRepository = new Repository\BookRepository($connection, $mapper, $entityFactory);

$books = $bookRepository->query()
    ->where('@tags.name', 'popular')
    ->where('DATE(@pubdate) > ?', '1998-01-01')
    ->find();

Veškeré @... výrazy se překládají na sloupce příslušných entity a tečková notace slouží k automatickému „left-joinování“. Položený dotaz potom vypadá takto:

SELECT [book].*
FROM [book]
LEFT JOIN [book_tag] ON [book].[id] = [book_tag].[book_id]
LEFT JOIN [tag] ON [book_tag].[tag_id] = [tag].[id]
WHERE [available] = 1 AND ([tag].[name] = 'popular') AND (DATE([book].[pubdate]) > '1998-01-01')

Pro backjoin se tedy používá pouze tečka (netřeba dvojtečky), protože příslušná vazba se vyčte ze třídy entity. Jak je vidět v dotazu, implicitní filtry se provedou.

Ukázka trochu komplikovanějšího dotazu:

$authorRepository = new Repository\AuthorRepository($connection, $mapper, $entityFactory);

$authors = $authorRepository->query()
    ->where('@books.tags.name', 'ebook')
    ->orderBy('@books.available')->desc()
    ->orderBy('@books.pubdate')
    ->find();

SELECT [author].*
FROM [author]
LEFT JOIN (
SELECT [book].*
FROM [book]
WHERE [available] = 1) book ON [author].[id] = [book].[author_id]
LEFT JOIN [book_tag] ON [book].[id] = [book_tag].[book_id]
LEFT JOIN [tag] ON [book_tag].[tag_id] = [tag].[id]
WHERE ([tag].[name] = 'ebook')
ORDER BY [book].[available] DESC , [book].[pubdate]

Pokud se má tedy „přijoinovat“ tabulka, na které se mají provést implicitní filtry, provede se složený dotaz, jak je vidět u joinování tabulky book.

Celý projekt je zatím ve fázi experimentování, proto budu vděčný za veškeré názory, podněty a bug reporty. Zajímá mě také kritika tohoto pohledu na Query Objecty, protože si sám nejsem zatím jistý, jestli to až příliš neporušuje některé principy, nicméně z mých dosavadních zkušeností mohu říct, že se mi takto pracuje s repozitáři zdaleka nejlépe ze všech mnou zatím vyzkoušených možností.

Editoval Michal III (29. 1. 2014 10:50)

@Tharos: Určitě cache na začátku vývoje a provozu aplikace nemá smysl řešit, ale pro testovaní možností zrychlení při zátěži by se nějaký ten příklad použítí asi mohl hodil nebo ne?

Je možné že Nette\Database je v posledním RC4 o hodně rychlejší než Dibi?

Je něco nového s dokumentací?

@kudlajz: Existují magické metody addTo<Name>, removeFrom<Name> (viz zde).

Takže ve Tvém případě:

$this->addToLikes(new Like);

Muze mi jeste nekdo poradit bliz s tim cachovanim? Jelikoz nelze serializovat entitu, jak mam postupovat? Radek se z db fetchuje pred volanim createEntity().

kudlajz napsal(a):

Muze mi jeste nekdo poradit bliz s tim cachovanim? Jelikoz nelze serializovat entitu, jak mam postupovat? Radek se z db fetchuje pred volanim createEntity().

Cachovat data co dostaneš přímo z databáze před vytvořením entity.
Cache, pokud není tak load z DB > createEntity

Nebo jsem cachoval celé komponenty (v render jsem bud nahral nové data z DB a klasicky vykreslil a nebo sem si načetl z cache celé html co jsem si do ní narval a vykreslil jej)

Editoval EIFEL (7. 1. 2014 21:08)

Nebylo by lepší, kdybych celé toto vlákno přesunul na dibi fórum?

Mesiah napsal(a):

Ahoj, prosím Vás jen drobnost.
Rád bych měl u entity property, kterou budu vytvářet na straně PHP (url vytvořená na základě hodnot aktuální entity), existuje v LM řešení ve stylu filter/passThru? Díky :)

Nestačili by ti na to normální metody ve stylu:

/**
 * @property string $name
 * @property string $surname
 * @property-read string $fullName
 */
class User extends \LeanMapper\Entity
{

  public function getFullName()
  {
    return $this->name . ' ' . $this->surname;
  }

}

@Mesiah: Jako optimální mi v takovém případě připadá mít službu pro generování odkazů (jak píšeš) a tu prostě předávat dané entitě jako závislost ve vlastní EntityFactory. V property (realizované pomocí metody) bys pak o tu URL žádal tu službu.

O pár stránek dříve (v době, kdy jsem představoval právě EntityFactory) najdeš pár ukázek, od kterých se dá dobře odrazit.

Kdybys tápal, klidně se ozvi přes soukromou zprávu.

Editoval Tharos (7. 1. 2014 23:58)

@Tharos Nějaké nové info ohledně dokumentace ? :)

Editoval EIFEL (13. 1. 2014 17:46)

@Tharos:

LQL mě také v souvislosti s tím napadlo. Je to sice věc, které by se asi spousta lidí bránila, že se „nechtějí učit další jazyk“, ale na spoustu případů by se velice hodila.

Na Poslední sobotu se právě vůbec poprvé chystám :-).

@Tharos: Jj, rád s Tebou tyhle věci proberu. Těším se :-).

Tharos napsal(a):

Jinak při hraní si s tím mě napadlo, že by vlastně šlo postavit nad Lean Mapperem robustní LQL.

Sice LM nepoužívám ale také by mě zajímalo co chystáš.. A také na kdy tak vidíš aktualizaci dokumentace pro verzi 2.x.x

Nobody.guy napsal(a):

Neocenil by někdo generování struktury databáze z vlastností v anotacích?

@Tharos už něco napsaného na to měl jen to myslím nebylo dotažené aby to zveřejnil.

Ahoj, mám dotaz ohledně práce s M:N vazbami.
Mám entitu Schedule:

/**
* @property int $id
* @property string|null $title
* @property Classroom[] $classrooms m:hasMany(schedule:gaudeo_classrooms_schedule:classroom:gaudeo_classrooms) m:filter(orderBySorting)
*/

Jak přidám nebo odeberu prvek z $classrooms ?
Doposud mi fungovalo

$schedule->addToClassrooms($classroom);
$schedule->removeFromClassrooms($classroom);

Jenže co jsem přidal filter nad property classrooms tak to nejde použít (Chyba: ‚Only properties without filters can be managed this way.‘)

Zkoušel jsem:

$cl = $schedule->classrooms;
unset($schedule->classrooms[$classroom->id]);
unset($schedule->classrooms[$classroom]);
unset($cl[$classroom->id]);
unset($cl[$classroom]);
$cl->remove($classroom);

ale nic z toho nefunguje – vždy se dostanu k nějaké chybové hlášce.

Díky, Filip

Filip111 napsal(a):

Jak přidám nebo odeberu prvek z $classrooms ?

Jenže co jsem přidal filter nad property classrooms tak to nejde použít (Chyba: ‚Only properties without filters can be managed this way.‘)

Myslím, že chybová hláška je celkem výmluvná, každopádně odpověď jak přidávat a odebírat je prostá – přes repository classroom(s). Teď by asi byla vhodná otázka: „Proč to nejde?“.
Na tohle neumím dostatečně správně a přesně odpovědět, ale řekl bych že to souvisí s filtry – to že při čtení se ke query připojí filtr je zřejmě, ale jak by se to mělo chovat při mazání?
Mělo by se to prohnat filtr? Nemělo? – Dokážu si představit oba scénáře.
Myslím, že Tharosovo rozhodnutí vyhodit chybu je na místě – tímhle by se aplikace chovala nepředvídatelně a mohlo by to vést ke špatně odhalitelným chybám – zvlášť ve vícečlenných týmech…
Víc by ti ale asi napsal Thahos. :)

Editoval Mesiah (28. 1. 2014 16:15)

@blur:

Jak pomocí mapperu dokážu automaticky řadit Modely do různých namespace? Zkoušel jsem pro každý repository vytvořit v konstruktoru mapper ale to mi vynadá, že nejsou totožné. Modely mám zvlášť pro každý modul a každá tabulka má v názvu jeho prefix. S tím zase souvisí odstranění anotace entity. Jak bez ní můžu repository nastavit Název entity kupříkladu tabulka security_users ⇒ User, tabulka content_articles ⇒ Article.

To, aby v celé aplikaci existoval pouze jeden Mapper, je poměrně důležité. Jde o to, že Mapper se předává při traverzování mezi entitami (úplně nenápadně) a pokud by existovalo více Mapperů, téměř by nešlo zabránit nechtěným chybám, kdy se najednou objeví entita A s Mapperem X (který získala při traverzování), namísto očekávaného Y (který by měla získat z repositáře).

Překlad security_users ⇒ User je přece jednoduchý, nebo ne? Pokud máš pevně danou logiku, můžeš odstřihnout tu část před potržítkem a upravit velikost prvního písmena. V Mapperu se ale nemusíš omezovat pouze na takovéto operace. Pokud máš například modulární aplikaci, Mapper klidně může interně používat nějaké překladové tabulky. Proměnnou $defaultEntityNamespace vůbec nemusíš používat.

Řeší má odpověď Tvůj problém?

@honos:

Tharos napsal(a):

Jinak při hraní si s tím mě napadlo, že by vlastně šlo postavit nad Lean Mapperem robustní LQL.

Sice LM nepoužívám ale také by mě zajímalo co chystáš.. A také na kdy tak vidíš aktualizaci dokumentace pro verzi 2.x.x

Dokumentace má rozhodně prioritu před podobnými experimenty. LQL by vytvořit šel, neexistuje žádný principiální problém, proč by nešel. Ale pokud zbude jeho realizace na mě, nějaký pátek ještě asi světlo světa nespatří. Ale třeba Michal III má nakročeno velmi hezky.

Editoval Tharos (29. 1. 2014 9:06)

@Filip111:

Ahoj, mám dotaz ohledně práce s M:N vazbami.

API pro správu jednoduchých M:N vazeb je záměrně nedostupné u položek s filtry.

Důvod je poměrně jednoduchý. Filtr s tou vazbou může udělat dost radikální věci. Například může k vazební tabulce přijoinovat nějaká data a programátor by se pak divil, že se mu pak entity „špatně“ persistují. Nebo může zavést restrikci, pomocí které se nějaká data vypustí. Mám-li vyfiltrované takové tagy knihy, které začínají na „S“ (třeba v položce tagsStartingByS), bylo by matoucí, kdyby do takové kolekce šlo přiřadit pomocí $book->addToTags nějaká tag začínající na „R“. Problém je třeba i s jednoduchým řazením. Pokud mám tagy nějak seřazené (třeba podle abecedy), spoléhám na to a někde v aplikaci si do takové property přiřadím nějaký další tag, mohu tím to seřazení narušit. No a dalo by se dlouze pokračovat.

Z výše uvedených důvodů je tedy to M:N API u takových vazeb uměle omezené. Dalo by se říct, že zavedením filtru ty vazby přestávají být jednoduché.

Principiálně tohle dost dobře vyřešit nelze. Alternativním řešením je například spravovat ty vazby přes repositář nebo mít v entitě ještě jednu ekvivalentní položku, jen bez toho filtru. Dále by to mohlo jít vyřešit i nějak „nízkoúrovňově“ v těle entity, což by mohlo být nejelegantnější řešení.

Edit: Tak „nízkoúrovňově“ by to šlo. V Row::(addTo|removeFrom)Referencing se už filtr nekontroluje, což je logické. Takže by v pohodě šlo v entitě si metodu například addToTags přetížit a vložení umožnit – ale na vlastní nebezpečí.

Editoval Tharos (29. 1. 2014 9:27)

@Tharos

Samozřejmě jen dotaz. :D

BTW: Jak kdyby si mi koukal do zrojáků :D Mám to teď napsané velmi podobně. :D

@blur, @Tharos:
Taky jsem narazil na problém s více mappery – konkrétně jsem přetraverzoval přes pár entit, upravil získanou entitu a nepodařilo se mi ji uložit, protože repository, které ji ukládá používalo jiný mapper než ten předaný při traverzování.
Dost mi to zkomplikovalo situaci.

Jak jsem se k tomu dostal?
Základem všech aplikací co dělám je zjednodušené CMS, která samo o sobě poskytuje některé „služby“ (ne nutně z kontaineru). Některé tyto „služby“ mají repository, entity a vlastní mapper.

Pak mám modul s nějakým firemním systémem, který ale používá služby cmska (práce s uživately, maily, logy, nějaká úložiště apod.). Tento modul má vlastní repository a entity a protože nechci aby o nich věděl standardní mapper cmska, mají i vlastní mapper se svými specialitami.
Entity tohoto firemního systému ale úplně klidně mohou být provázané na entity cmska (na uživatele, nějaký typové číselníky, tagy atd).

Pravidlo jediného mapperu je tedy dost svazující při snaze rozdělit aplikaci na více modulů.
(řešení v LM mě nenapadá, jen chci upozornit, že to není tak černobílé)

@Tharos, @honos, @Michal III
Vážně potřebujeme LQL a převod entit na tabulky, resp. SQL?
LeanMapper je Lean a proto ho používám, kolos který umí všechno už tu máme (Doctrine2) a přijde mi zbytečný vytvářet ho znovu.

@Filip111:

Pravidlo jediného mapperu je tedy dost svazující při snaze rozdělit aplikaci na více modulů.
(řešení v LM mě nenapadá, jen chci upozornit, že to není tak černobílé)

Důvod, proč to tak ale je, je věřím jasný. Vůbec si nemyslím, že by to bylo nějak svazující. Jen je zapotřebí nevnímat Mapper jenom jako nějaký „tupý“ aplikátor nějakých konvencí. Může fungovat úplně dynamicky:

class DynamicMapper extends DefaultMapper
{

    private $dictionary = array();


    public function registerModule($modulePrefix, array $names)
    {
        foreach ($names as $name) {
            $this->dictionary[$modulePrefix . '_' . $name] = 'Addon\\' . ucfirst($modulePrefix) . '\\Entity\\' . ucfirst($name);
        }
    }

    public function getEntityClass($table, Row $row = null)
    {
        if (isset($this->dictionary[$table])) {
            return $this->dictionary[$table];
        }
        return parent::getEntityClass($table, $row);
    }

}

$mapper = new DynamicMapper;

$mapper->registerModule('news', array('item', 'comment', 'rating'));
$mapper->registerModule('content', array('page', 'text'));

$entityClass = $mapper->getEntityClass('news_item'); // $entityClass === 'Addon\News\Entity\Item'
$entityClass = $mapper->getEntityClass('news_rating'); // $entityClass === 'Addon\News\Entity\Rating'
$entityClass = $mapper->getEntityClass('content_page'); // $entityClass === 'Addon\Content\Entity\Page'

Pak není problém, aby si každý modul CMS při svém zavádění zaregistroval do Mapperu entity, které do „ekosystému“ přidává. Uvedená ukázka je záměrně triviální, v praxi by byl kód asi o něco složitější, ale věřím, že je z toho patrné, co chci říct.

Vážně potřebujeme LQL a převod entit na tabulky, resp. SQL?
LeanMapper je Lean a proto ho používám, kolos který umí všechno už tu máme (Doctrine2) a přijde mi zbytečný vytvářet ho znovu.

Jde o věci, které by v žádném případě nebyly nějakou nativní součástí Lean Mapperu, ale jen nadstavbou nad ním.

Generování tabulek z anotací (respektive z EntityReflection) je lákavé, protože díky existenci EntityReflection je to hračka a takové generování prostě při vývoji ušetří dost času.

Bez LQL se dá obejít. Je to prostě jeden ze způsobů, jak vyjádřit to, jaké entity a jakým způsobem se mají z úložiště načíst. Pokud by jej někdo naprogramoval, věřím, že by si své uživatele našel. Z Lean Mapperu to kolos ale určitě neudělá, do něj to nijak nezasáhne. Půda už je v podstatě připravená (EntityReflection, IMapper).

Editoval Tharos (30. 1. 2014 8:49)