Lean Mapper – tenké ORM nad dibi

@castamir:

1. Zrovna tohle tu teď řeším, jestli jsi mé příspěvky četl. Pokud bych se dal na zmíněnou první metodu, tenhle problém kompletně odpadá. Nicméně dá se říci, že ano, vytváří se hůře.
2. Tohle je obecně problém ORM typu Lean Mapper. Tak je prostě nastavená jeho architektura, že neperzistovaná entita se nemůže dožadovat vztahových entit. Stejně tak to teď bude s těmi závislostmi, pokud nebudeš vše vytvářet přes faktory.
3. Tohle není ale problém vývojáře. To, že někdo nechápe principy architektury kterou potažmo využívá je jeho problém. Rozhodně je podle mě blbost si říct: „tuhle skvělou feature raději nebudu vyvíjet, protože neznalí programátoři s tím napáchají akorát škody“. To bych podle tvé logiky mohl říct, že DI je taky špatná. Vždyť přeci neznalý programátor pak může kombinovat DI se statickým voláním a to už je teprve peklo, kdyby to po něm někdo přebral a domníval se, že předáním závislostí je vše vyřešené.

Editoval Casper (13. 11. 2013 14:46)

@Michal III:

Tharos má ve svém skeletonu na githubu metodu pro naplnění formuláře v BaseEntity. Osobně se mi více líbí si napsat podobnou, ale obecnější metodu getPreviewData, která jen potřebná data získá. Tu pak můžu využít nejen pro fomuláře.

@Casper, @Michal III: Mně se ta má metoda v BaseEntity vůbec nelíbí, sám bych ji určitě nikde neventiloval. :)

Nejde ani tak o její vnitřnosti, ty nejsou špatné, ale hlavně o její umístění – entita by neměla o žádných formulářích nic vědět. To mé řešení ve skeletonu je prostě dirty ad-hoc solution.

V jednom projektu mám rozpracované řešení, které mi přijde mnohem lepší – potřebnou logiku zapouzdřuje formulář a já pak jenom volám něco jako $form->setDefaults($entity). Akorát to taky ještě není v takovém stavu, abych to mohl s čistým svědomím pustit ven… :(

Editoval Tharos (14. 11. 2013 2:00)

@castamir:

krom toho, že to narušuje single responsibility principle

Vezmeme-li v úvahu tuto definici SRP:

A class or module should have one, and only one, reason to change.

pak neplatí, že existence metody Entity\Order::notifyAdmin je automaticky porušením SRP. Záleží na tom, jestli ta entita tu práci sama dělá, anebo ji jen deleguje. Moc doporučuji tento článek od René Steina, se kterým osobně naprosto souhlasím.

1. mnohem hůř vytváří vytváří instance (rozumněj, stále bude možné vytvořit instanci pouze přes new a kdo to pak ošetří, když ta instance nebude mít připojené patřičné služby?)

To je prostě cena dependency injection…

to, že si pár lidí nejspíš bude schopno pohlídat, co za závislosti s entitou propojí, aby z toho nevznikla totální prasečina je jedna věc, druhá ale je, že spoustu dalších vyloženě naočujete tímto použitím a oni si to pak budou uplatňovat za všech okolností a ten guláš jim v tom vznikne…

Tohle je přesně důvod, proč mi anémický model u data-centric aplikací nepřijde jako vůbec špatný. Je prostě blbuvzdorný, neklade vysoké nároky na programátora. Jasně separuje data a práci s nimi, takže programátor hned ví „co kam šoupnout“. Nevyužívá se naplno možností OOP, ale, mezi námi… u většiny webových aplikací je to víceméně fuk.

Rich-domain model je rozhodně těžší navrhnout a pokud to programátor udělá špatně, výsledek bude pravděpodobně hůře použitelný a udržovatelný než anémický model řešící stejné zadání.

Ahoj,

Lean Mapper má od včerejšího dne jednu zajímavou novou funkcionalitu, které říkám implicitní filtry.

Vezměme si například toto zadání. Lze to velmi přímočaře vyřešit pomocí filtru, který do SQL dotazu doplní restrikci deleted = 0. Problémem ale je, že takový filtr musíme explicitně použít všude tam, kde se daná entita načítá – v repositáři a ve všech entitách, které se na tu zmíněnou odkazují (mají na ní vazbu). Jinak bychom se někde mohli například dotraverzovat i k odstraněným entitám. Obrovskou nevýhodou je, že zapomenout někde ten filtr uvést je velmi snadné.

No a tohle řeší ony implicitní filtry. Stačí v mapperu říct, že při načítání té či oné entity se vždy mají použít vybrané filtry. Slouží k tomu nová metoda IMapper::getImplicitFilters, která vrací buďto pole s názvy těch filtrů, anebo instanci ImplicitFilters která kromě těch názvů obsahuje i parametry, které se jim mají předat. Fungují podobně jako pátý parametr konstruktoru třídy Filtering.

Ukažme si, jak lze pomocí tohoto konceptu vyřešit výše odkázané zadání:

/**
 * @property int $id
 *
 * @property Category $category m:hasOne
 *
 * @property string $title
 * @property DateTime $published
 * @property string $text
 */
class Article extends \LeanMapper\Entity
{
}

/**
 * @property int $id
 *
 * @property Article[] $articles m:belongsToMany
 *
 * @property string $name
 */
class Category extends \LeanMapper\Entity
{
}

class Repository extends \LeanMapper\Repository
{

    public function findAll()
    {
        return $this->createEntities(
            $this->createFluent()->fetchAll()
        );
    }

}

class ArticleRepository extends Repository
{

    protected function deleteFromDatabase($arg)
    {
        $primaryKey = $this->mapper->getPrimaryKey($this->getTable());
        $idField = $this->mapper->getEntityField($this->getTable(), $primaryKey);

        $id = ($arg instanceof Entity) ? $arg->$idField : $arg;
        $this->connection->query(
            'UPDATE %n SET [deleted] = 1 WHERE %n = ?', $this->getTable(), $primaryKey, $id
        );
    }

}

class CategoryRepository extends Repository
{
}

class Mapper extends TestMapper
{

    public function getImplicitFilters($entityClass, $caller = null)
    {
        if ($entityClass === 'Article') {
            return new ImplicitFilters(array('living'), array(
                'living' => array($this->getTable($entityClass))
            ));
        }
        return parent::getImplicitFilters($entityClass, $caller);
    }

}

////////////////////

$mapper = new Mapper;

$connection->registerFilter('living', function ($statement, $table) {
    $statement->where('%n.[deleted] = 0', $table);
});

To je v podstatě vše. Všimněte si následujících záležitostí v kódu:

1. Repository obsahuje novou protected metodu createFluent, jejíž implementace je myslím snadno pochopitelná. Jednak zase o něco usnadňuje život (nemusíte datlovat ani obligátní $this->connection->select(...)->from($this->getTable())->fetchAll(), ale hlavně hlídá, aby byly ihned aplikovány všechny potřebné implicitní filtry, takže na ně nelze zapomenout.

2. Při definici vazby z entity Category na entitu Article není nutné uvádět žádné filtry, protože díky implicitnímu filtru je už zaručené, že se vždy načtou pouze nesmazané články. Takže jsme si zase ušetřili nějaké psaní a také jsme eliminovali riziko, že nějaký filtr uvést zapomeneme.

3. Repositář ArticleRepository velmi jednoduše namísto trvalého odstraňování záznamů jen nastavuje deleted = 1.

Zavoláme-li pak v aplikaci $articleRepository->findAll(), položí se dotaz:

SELECT * FROM `article` WHERE `article`.`deleted` = 0

A provedeme-li pak v aplikaci následující aktivitu:

foreach ($categoryRepository->findAll() as $category) {
    echo $category->name, "\n";
    foreach ($category->articles as $article) {
        echo "  ", $article->title, "\n";
    }

}

Položí se dotazy:

SELECT * FROM `category`
SELECT `article`.* FROM `article` WHERE `article`.`category_id` IN (1, 2) AND `article`.`deleted` = 0

Všimněte si, že se korektně načítají pouze neodstraněné články a nemusíme na to téměř nijak myslet.

Celý tento koncept má velmi široké uplatnění. Například ten systém překladů, který jsem zde na fórum už kdysi dával, by se mohl ještě zjednodušit: ty filtry m:filter(translate) by se vůbec nemusely uvádět, čímž by zároveň odpadlo riziko, že takový filtr někde uvést zapomenete. Asi ten příklad ještě zaktualizuji. :)

Enjoy!

Editoval Tharos (15. 11. 2013 15:00)

@Tharos: Paráda! Děkuji.

Editoval Michal III (15. 11. 2013 12:45)

@llook: Samozřejmě, že lze takové filtry „přebíjet“. Ony se kombinují s těmi explicitně uvedenými. Platí, že se nejprve volají ty implicitní a pak ty explicitní, ale s tím, že pokud je uveden v explicitních filtrech (třeba v příznaku m:filter) nějaký filtr, který je obsažen i v implicitních, tak se v těch implicitních ignoruje a volá se až později (v rámci zpracování těch explicitních). Tak lze efektivně ovlivnit pořadí volání filtrů a také lze v tom příznaku explicitně přetížit „fixní parametry“, které se filtru předají.

Ono se to fakt kostrbatě popisuje, v dokumentaci tohle asi budu muset polopaticky ukázat na nějakých příkladech… Ale mělo by to být velmi pružné.

Pokud bys chtěl implicitně ten filtr living používat, ale zároveň bys chtěl mít možnost vypisovat i smazané záznamy, je hned několik možností, jak to vyřešit. Já bych asi nepohrdl následujícím řešení (i když by záleželo na kontextu):

Upravuji výše uvedený příklad.

const EXCLUDE_DELETED = 0; // tyhle mrchy bych určitě nenechal v globálním prostoru…
const INCLUDE_DELETED = 1;

$connection->registerFilter('living', function ($statement, $table, $mode = EXCLUDE_DELETED) {
    if ($mode === EXCLUDE_DELETED) {
        $statement->where('%n.[deleted] = 0', $table);
    }
});

// kdesi v relevantním repository

public function findAllIncludingDeleted()
{
    return $this->createEntities(
        $this->createFluent(INCLUDE_DELETED)->fetchAll() // zde lze předat filtrům dynamický parametr tak, jako při volání Entity::getXyz($arg1, $arg2, ...)
    );
}

foreach ($articleRepository->findAllIncludingDeleted() as $article) {
    echo $article->title, "\n";
}
// SELECT `article`.* FROM `article`

foreach ($categoryRepository->findAll() as $category) {
    echo $category->name, "\n";
    foreach ($category->getArticles(INCLUDE_DELETED) as $article) {
        echo "  ", $article->title, "\n";
    }
}
// SELECT `category`.* FROM `category`
// SELECT `article`.* FROM `article` WHERE `article`.`category_id` IN (...)

Samozřejmě by bylo možné i nadefinovat přímo getter getArticlesIncludingDeleted bez potřeby předávání parametru atp. Ale jak říkám, ono by to šlo řešit hned více způsoby. Pokud by Ti například createFluent(INCLUDE_DELETED) přišlo příliš magické, šlo by tu část nahradit ručním vytvořením dotazu.

Co se té hasOne vazby týče, při traverzování přes ní se implicitní filtry samozřejmě aplikují. Jak přesně bys chtěl smazat položku, na které je nějaká jiná závislá? Máš na mysli situaci, kdy bys měl třeba načtený článek, který je navázaný na smazaného autora, a k tomu autorovi traverzoval? Lean Mapper jej z databáze nenačte a vrátí pro tu property hodnotu null (musí tedy být typu Author|null, ale to myslím dává smysl a je žádoucí).

Anebo jsi měl na mysli ještě něco jiného? :)

Editoval Tharos (15. 11. 2013 22:44)

@Tharos: Myslím, že u toho traverzovaní přes vazvu hasOne je mnohdy právě žádoucí, aby se vrátil i soft smazaný autor – tedy situace, kdy bychom „living“ autory používali jako autory, se kterými můžeme dál pracovat (přidávat jim knihy), ale zároveň bychom pro knihy se smazanými autory stále chtěli autora vypisovat. (Tohle je zrovna trochu nešikovný příklad, ale představme si tedy něco podobného s mobilními operátory a tarify. Tarify bychom časem chtěli odstranit z nabídky, přičemž by ale ještě existovali lidé, kteří by ho měli aktivovaný…

@Michal III, @llook: Jasně, už to chápu. :) V podstatě jde o to, jak nasimulovat to, co za nás u standardního delete běžně řeší cizí klíče: SET NULL, RESTRICT, CASCADE…

Troufám si tvrdit, že to lze v Lean Mapperu vcelku přímočaře vyřešit. To, jak lze na vyžádání načíst i záznamy označené jako smazané, jsem nastínil. Pokud jde o zachování konzistence při označování záznamů jako smazaných, šlo by postupovat následovně:

1. Navěsil bych si handler na událost AFTER_DELETE (pro entitu, která se reálně nemaže).
2. V tom handleru bych řešil ony závislé entity. Ty bych našel třeba pomocí RobotLoaderu – naindexoval bych si všechny entity a za použití EntityReflection bych vyfiltroval ty, které potenciálně mají na mazanou entitu vazbu.
3. Načetl bych ty, které tu vazbu reálně mají (podle ID mazané entity), a podle potřeby bych se s tou vazbou vypořádal.

Vznikl by tak plně automatizovaný systém bez potřeby dodatečné konfigurace po přidání nových entit nebo vazeb mezi nimi.

Tharos napsal(a):

Jak jsem naznačil, aktualizoval jsem ukázku s překlady tak, aby naplno využívala nejnovějších schopností Lean Mapperu, zejména implicitních filtrů.
\--

@Tharos Super :) zrovna nedávno sem se do těch překladů pustil a todle ušetří další čas :)
btw kdy plánuješ vydat další Releases?

Editoval EIFEL (18. 11. 2013 15:48)

Michal III napsal(a):

@Tharos: Možná došlo k nedorozumění v mém příspěvku, ale mně by opravdu šlo o to (a také by se mi to zrovna hodilo), aby se implicitní filtry aplikovaly jen na repozitáře a jen určité druhy vazeb při traverzování – tedy vyjma hasOne, u které bych chtěl, aby filtry použity nebyly a nebylo mi navráceno NULL, nýbrž soft smazaná položka. Lze tohoto nějak docílit?

Tohle chceš u filtrů, které nějak filtrují výsledek. Ale taky můžou být filtry, které třeba přidávají vypočítané hodnoty, nebo joinují další tabulku a takové filtry chceš aplikovat vždycky.

Vidím dvě možnosti – buďto ty filtrovací implicitní filtry budeš u každé hasOne vazby přebíjet explicitním filtrem, nebo naopak ty filtrovací filtry nebudou implicitní, ale explicitně uvedené u každé vazby, na kterou se mají aplikovat.

@EIFEL: Z featur byly ty implicitní filtry asi tím posledním, co jsem ve verzi 2.1 ještě vyloženě chtěl mít. Takže cca do konce týdne otevřu release větev. Finální verze 2.1 by tedy měla spatřit světa velmi brzy.

Editoval Tharos (18. 11. 2013 21:26)

Tharos napsal(a):

Jak jsem naznačil, aktualizoval jsem ukázku s překlady tak, aby naplno využívala nejnovějších schopností Lean Mapperu, zejména implicitních filtrů.

Řekl bych, že se celá věc zase zjednodušila. Máme-li takovouto implementaci getImplicitFilters:

public function getImplicitFilters($entityClass, $caller = null)
{
  if (is_subclass_of($entityClass, 'Model\Entity\TranslatableEntity')) {
      if ($caller instanceof Entity) {
          return array('translateFromEntity');
      } else {
          return new ImplicitFilters(array('translate'), array(
              'translate' => array($this->getTable($entityClass)),
          ));
      }
  }
  return parent::getImplicitFilters($entityClass, $caller);
}

Nebylo by lepší používat defaultEntityNamespace než mít natvrdo nastaven namespace entit?
Beru zpět :)

if (is_subclass_of($entityClass, $this->defaultEntityNamespace . '\TranslatableEntity')) {...}

Tharos napsal(a):

@EIFEL: Z featur byly ty implicitní filtry asi tím posledním, co jsem ve verzi 2.1 ještě vyloženě chtěl mít. Takže cca do konce týdne otevřu release větev. Finální verze 2.1 by tedy měla spatřit světa velmi brzy.

Super :)

Editoval EIFEL (20. 11. 2013 0:14)

@Tharos: +1

@EIFEL: Samozřejmě, že je to možné. :) Není to ani nic složitého.

Upravil jsem Ti tu ukázku tak, aby v po prvotním načtení všech jazyků nedošlo už k žádnému dalšímu dotazu do tabulky s jazyky: http://www.leanmapper.com/…lations2.zip

Pointou je, že ty musíš do všech míst, kde jsou zapotřebí, předat kolekci načtených jazyků (v praxi se jedná pouze o Translator a o potomky TranslatingRepository). Já ji v té upravené ukázce předávám jako asociativní pole, ale v reálu bych si z toho samozřejmě udělal službu s nějakým jasně daným API a ve výsledku by veškeré předávání vyřešil auto wiring.

Mimochodem s tímto řešením ty jazyky klidně ani nemusí být v databázi, mohou existovat třeba jen v nějakém konfiguračním souboru.

Ahoj, na stránkách jsem se dočetl, že „Název tabulky lze upřesnit pomocí anotace @table a třídu entity lze upřesnit pomocí anotace @entity (obě anotace patří nad třídu repositáře).“ a protože nedodržuji konvence, tak bych konkrétně anotaci @entity potřeboval použít. To však nefunguje a nikde jsem se nedočetl, že by fungovat neměla. Musím ručně používat $entityClass v createEntity() což se mi ale nelíbí. Jak je to tedy?

Druhá věc. Do teď jsem používal Nette\Database a po přechodu na Dibi se mi nelíbí to, že neumí predikci SELECTů, ale všude v příkladech se používá SELECT *, což se mi nelíbí. Dá se toto v Leanu nějak pěkně vyřešit?

Díky.

EIFEL napsal(a):

1. Mám takovej dojem (nejsem si tím opravdu jistej), že se anotace @entity a @table odstranila. Toto se řeší pomocí mapperu, takže pokud nedodržuješ konvence základního mapperu tak si vytvoř svůj, který ti bude vyhovovat
2. Todle je zase otázka repozitářů. Jak si složíš SQL dotaz takovej ho máš, jen nevím jak se bude chovat persistování entity.

Tak to by bylo matoucí, protože @table funguje, to také využívám. Na mapper jsem úplně zapomněl. To by asi šlo. Díky.

U Nette\Database jsem si právě zvykl nepoužívat SELECT vůbec, což je maximálně pohodlné. Každopádně zatím se do tohoto návrhu dostávám, takže to asi nebudu teď řešit…

Umí si LeanMapper poradit s use statementy předků? Tj:

namespace Model\Entity;
use DateTime;

/**
 * @property DateTime $date
 */
class Predek extends \LeanMapper\Entity
{

}

//v jiném souboru

namespace Model\Entity;

class Potomek extends Predek
{

}

Totiž mně to při používání tímto způsobem pak hází:

LeanMapper\Exception\InvalidValueException

Property ‚date‘ is expected to contain an instance of Model\Entity\DateTime, instance of DibiDateTime given.

pokud přistupuji k date instance Potomek ($potomek->date).

@mrtnzlml:

Ahoj, na stránkách jsem se dočetl, že „Název tabulky lze upřesnit pomocí anotace @table a třídu entity lze upřesnit pomocí anotace @entity (obě anotace patří nad třídu repositáře).“ a protože nedodržuji konvence, tak bych konkrétně anotaci @entity potřeboval použít. To však nefunguje a nikde jsem se nedočetl, že by fungovat neměla. Musím ručně používat $entityClass v createEntity() což se mi ale nelíbí. Jak je to tedy?

Je to tak, že ty anotace byly tak trochu reliktem z doby, kdy ještě neexistoval samostatně stojící mapper. Chvíli jsem je udržoval i po představení mapperu, ale jakmile Lean Mapper začal podporovat single table inheritance, ty anotace přestaly fungovat dobře. Uměly se s mapperem „tlouct“ (mohly tvrdit něco jiného než mapper), a proto jsem je odstranil. Respektivě odstranil jsem anotaci @entity, která skrývala více potenciálních problémů. Anotace @table se stále ještě bere v potaz.

Mapper by je měl plně nahrazovat. Vím, že mi píšeš na Gitu – odpovím i tam. :)

Druhá věc. Do teď jsem používal Nette\Database a po přechodu na Dibi se mi nelíbí to, že neumí predikci SELECTů, ale všude v příkladech se používá SELECT *, což se mi nelíbí. Dá se toto v Leanu nějak pěkně vyřešit?

V ORM je obecně žádoucí mít entity plně inicializované, byť to s sebou nese nějakou režii. Pokud bys ale někde opravdu chtěl načíst jenom „část entity“, můžeš se podívat na tento můj prastarý příspěvek. Dnes by to díky implicitním filtrům mělo být ještě snazší.

Přímo koncept „předbíhání budoucnosti“ není v Lean Mapperu naimplementován.

mrtnzlml napsal(a):

Jak už psal EIFEL, pokoušel jsem se napsal v mapperu metodu getEntityClass tak, aby uměla přistoupit k dokumentačnímu komentáři repozitáře, ale to neumím. Jak na to, když mám BlogArticleRepository (obecně jakýkoliv repozitář), který dědí od ARepository, který dědí od LeanMapper\Repository, který volá metodu getEntityClass z mapperu? Pokud se dostanu nějakým rozumným způsobem k tomu komentáři, tak napsat si vlastní anotaci už není problém…

Nepřijde mě to jako moc dobrej nápad zatahovat do mapperu repozitáře.

Editoval EIFEL (24. 11. 2013 12:11)

mrtnzlml napsal(a):

EIFEL napsal(a):

Nepřijde mě to jako moc dobrej nápad zatahovat do mapperu repozitáře.

Ok, pak se ale vracím k problému, který ještě nikdo nedokázal konkrétně zodpovědět. Tím co jsem zde psal jsem navazoval na https://github.com/…per/issues/8#…, konkrétně na „you can even parse @entity annotation above repository class from your custom mapper“…

Nebráním se jinému řešení, ale zatím opravdu jako nejlepší vychází při psaní repozitáře specifikovat jaká entita se má používat. Jenže když bych neměl zatahovat repozitář do mapperu, pak padla také myšlenka, že by mělo existovat v mapperu něco jako překladová tabulka table ⇒ entity a zase mi přijde dost nelogické při psaní repozitáře zasahovat do nějakého mapperu, který ani není vidět, že se používá a přidávat novou hodnotu do slovníku…

Nebo existuje ještě jiné maximálně elegantní řešení, jak specifikovat se kterou entitou a tabulkou má repozitář pracovat?

Udělal bych si překladovej slovník v mapperu. Sice to nebudeš mít ihned po ruce, když budeš psát repozitář ale budeš to mít všechno na jednom místě v mapperu a nic tě nebrání si ho rozšířit (pokud implementujes IMapper) o ten překladovej slovník.

Editoval EIFEL (24. 11. 2013 13:30)

@mrtnzlml:

Ještě jednou jsem jsi přečetl to Tvé zadání:

I have database, with namespaced tables (blog_articles, set_options, sys_issues, sys_logins and so on). But I want to specify, that entities are BlogArticle, Issue, Login…

Neřešme nyní repositáře. Máme tedy prefixované tabulky blog_articles, set_options, sys_issues atp. a potřebujeme vyjádřit, že v tabulce blog_articles jsou data pro entity BlogArticle, v sys_issues jsou data pro Issue a tak dále.

Přesně k tomu slouží metody IMapper::getEntityClass($table, Row $row = null) a IMapper::getTable($entityclass) – tyto metody prostě musí vracet správné hodnoty pro různé vstupy. Jestli jejich implementace bude využívat nějakého výčtu přímo v kódu, nějakého konfiguračního souboru, nějaké speciální tabulky v databázi… už je vedlejší.

Pak zde máme repositáře. Řekněme, že budeme mít repositáře BlogArticleRepository, IssueRepository a tak podobně. Ty lze „namapovat“ buďto pomocí anotace @table (@table blog_articles nad BlogArticleRepository, @table sys_issues nad IssueRepository atp.), anebo implementací metody IMapper::getTableByRepositoryClass. Já bych v tomto případě spíše využil anotaci @table – na tohle se přesně hodí a takové řešení neskrývá žádná skrytá rizika.

Je to řešení Tvého problému? :)

Důvodem, proč mapování sys_issues → Issue a podobné musí být v mapperu a ne jen v nějaké anotaci nad repositářem, je to, že tyhle detaily nezajímají jenom repositáře. Architektura Lean Mapperu je taková, že entita pro načtení těch entit, na které má vazbu, nepotřebuje odpovídající repositáře, nýbrž se k nim umí dotraverzovat „svépomocí“. K tomu ale potřebuje znát detaily O/R mapování a pokud by byly zapsané jen někde v anotaci nad nějakým repositářem, nebyly by jí nic platné (entity nemají na repositářích vůbec žádnou závislost, vůbec o nich neví). Ona se ptá mapperu.

Tohle je přesně důvod, proč anotace @entity nefungovala dobře a proč byla zrušena.

Editoval Tharos (25. 11. 2013 0:37)

@jannek19: V Tvém případě se budeš muset rozhodnout, co necháš na databázi (v podobě pohledu, uložených procedur a tak podobně) a co necháš v „objektech“. Pravděpodobně by to s Lean Mapperem celé šlo vyřešit v „objektech“, jsem přesvědčen, že by ses obešel i bez té uložené metody saveArticle. Ale vůbec není na překážku – lze ji využít z repositáře při persitenci, přesně, jak píšeš.

Osobně bych asi vynechal ten pohled pro join dat z article a revision, protože to lze v Lean Mapperu velmi snadno propojit pomocí filtru. Psáno z hlavy by to mohlo vypadat nějak takhle:

// CustomMapper.php
public function getImplicitFilters($entityClass, Caller $caller = null)
{
    if ($entityClass === 'Model\Entity\Article') {
        return new ImplicitFilters(function ($statement) { // tzv. anonymní filtr, novinka, o které se akorát chystám napsat na fórum :)
            $statement->select('[revision].]')->join('revision')->on('[task.revision_id] = [revision.id]')
        });
    }
}

Entita Model\Entity\Article pak bude zapoudřovat už ta spojená data. Úplně stejně, jako by zapouzdřovala data z Tvého view.

Problémy s automatickým vytvářením nových revizí bys mít neměl, protože ty můžeš v repositáři v rámci persistence libovolně upravit data entity. Prostě když zjistíš, že update vedl například k vytvoření nového záznamu v tabulce revision, tak jen nastavíš jeho ID do entity Article a na závěr zavoláš ještě v repositáři $article->markAsUpdated(), aby se při příští persistenci neměl tendenci volat update toho sloupce s cizím klíčem.

Osobně v tom pak už nevidím žádné zádrhely. Jinými slovy: pokud ti při persistenci uložená procedura saveArticle změní stav dat, není problém ty změny reflektovat do entity ještě před tím, než ji vrátíš z repositáře ven.

Mám můj popis hlavu a patu a je srozumitelný? :)

Díky, takto mi to stačí. Vždy jsem se pokoušel v mapperu získat aktuálně používaný repozitář, což se ale ukázalo jako docela náročný úkol. Toto řešení mě nenapadlo a je to konečně něco u čeho již mohu říct ano, to jsem hledal. (-: Díky za pomoc a inspiraci…

Ahoj,

píšu nový quick start (který bude součástí nové dokumentace) a vymyslel jsem si zadání s „nenulovou“ doménovou logikou. Představený model bude někde na pomezí mezi anémickým a rich domain.

Jak tak quick start píšu, napadají mě různé nápady, které se většinou ihned snažím převést v realitu. Na GitHubu teď přibylo pár novinek, které bych zde postupně rád představil. A začnu tím, čemu říkám:

Anonymní filtry

Jde o úplně jednoduchý koncept. Mějme nějaký absolutně jednoúčelný filtr, který má v celém modelu smysl použít jen na jednom jediném místě. Například máme knihu s přiřazenými tagy a chceme mít v entitě Book read only položku isEbook, která vrátí boolean hodnotu vyjadřující, zda kniha má přiřazen jeden vybraný tag (třeba s názvem „ebook“).

Lze na to napsat krásný stručný filtr. Doteď ale bylo nutné ten filtr pojmenovat (otrava), zaregistrovat v Connection (další otrava) a teprve pak jej bylo možné využít.

Nově instance Filtering a ImplicitFilters přijímají jako první argument nejen pole s názvy filtrů, ale i s instancemi Closure, kterým se předává Fluent a dynamicky předané parametry. Pole může obsahovat klidně i mix názvů filtrů s instancemi Closure a dále také platí, že pokud chcete použít jenom jeden filtr (ať už daný jako název nebo Closure), může se předat přímo (nemusí se předávat v rámci pole s jedním prvkem), viz ukázka v tomto postu.

Těmto anonymním filtrům nejde autowirovat entitu ani property a nejde jim ani předat žádné targeted args (což je pochopitelné, nelze na ně odkazovat názvem), ale to vůbec nevadí, protože vše lze do filtru dostat pomocí use při vytváření Closure.

Takto tedy může takový anonymní filtr vypadat v praxi:

/**
 * @property int $id

 * @property Tag[] $tags m:hasMany

 * @property string $name
 * @property string|null $description
 * @property string|null $website
 * @property-read bool $isEbook m:useMethods(isEbook)
 */
class Book extends \LeanMapper\Entity
{

    /**
     * @return bool
     */
    public function isEbook()
    {
        $filtering = new Filtering(function (Fluent $statement) {
            $statement->join('tag')->on('[book_tag.tag_id] = [tag.id]')
                    ->where('[tag.name] = "ebook"');
        });
        $rows = $this->row->referencing('book_tag', null, $filtering);
        return !empty($rows);
    }

}

Enjoy!

Editoval Tharos (25. 11. 2013 14:26)