Lean Mapper – tenké ORM nad dibi

Tohle mi přijde tak magický, že by na to čuměl i Harry Potter. Mě magie nevadí, pokud má nějaké relevantní opodstatnění, ale zavádět toto kvůli ušetření pár znaků by mi přišlo šílené.

Bylo to čistě z pragmatického důvodu, že zrovna u této vazby na to furt zapomínám :D

@castamir: Máš to mít. :)

Návrh/dotaz, jestli je to vůbec možné: podpora pro vícesloupcové primární klíče.

@Casper: Tohle je samozřejmě chyba (do té metody createEntity jsem tu podporu prostě přidat zapomněl :–P). Opraveno v develop větvi.

@looky: Aktuálně nejsou vícesloupcové primární klíče podporované. Provedu rešerši, co by její zavedení obnášelo.

@castamir: Já vím, já vím. :) Nicméně do verze 1.5 už mi chybí opravdu málo: upravit ten parser anotací (podle RFC tady na fóru) a taky bych do ní ještě chtěl zahrnout tu úpravu filtrů. Odhaduji, že tak do deseti dní bude venku.

Pak zase hurá na dokumentaci. ;)

Editoval Tharos (16. 7. 2013 19:41)

ad vícesloupcové PK) Tak jsem provedl bleskovou rešerši. Není to vůbec triviální záležitost (hlavně kvůli IN).

Koukal jsem, jak je na tom „konkurence“. Nette\Database ani NotORM plnokrevné vícesloupcové primární klíče AFAIK neumí. Cituji z NotORM dokumentace:

Does NotORM support multi-column primary keys?
Yes. What NotORM does not support is multi-column foreign keys. So it is valid to define a two-column primary key in M:N table but it is not possible to use a foreign key pointing to (type, id_type) – this is rarely used. Methods getPrimary, getReferencingColumn and getReferencedColumn must return a single column.

Lean Mapper je na tom nyní v podstatě stejně. Spojovací tabulky mohou mít pouze dva sloupce a nad nimi primární klíč.

Neslibuji, že podpora pro tohle bude lepší, protože bych si mohl pěkně naběhnout…

Editoval Tharos (16. 7. 2013 22:14)

@Casper: Díky za kladný ohlas. :) Snad Tě potěší, že všechny problémy, o kterých píšeš, mají IMHO snadné řešení. :) Jen je znát, že ještě není dokumentace pro plánovanou verzi 1.5 (po jejím vydání si zase k dokumentaci sednu).

ad 1, 2, 4) Ty potřebuješ zhruba následující Mapper:

class Mapper extends LeanMapper\DefaultMapper
{

    public function getPrimaryKey($table)
    {
        return $table . '_id';
    }

    public function getRelationshipColumn($sourceTable, $targetTable)
    {
        return $this->getPrimaryKey($targetTable);
    }

    public function getTable($entityClass)
    {
        // dopsat automatickou konverzi ala Model\Entity\DeliveryType -> delivery_type
        // doporučuji inspirovat se zde: https://api.nette.org/2.0/source-Application.Routers.Route.php.html#688-715
    }

    public function getEntityClass($table, Row $row = null)
    {
        // dopsat automatickou konverzi ala delivery_type -> Model\Entity\DeliveryType
        // vhodná inspirace viz výše
    }

    public function getColumn($entityClass, $field)
    {
        // dopsat automatickou konverzi ala bankNumber -> bank_number
        // vhodná inspirace viz výše
    }

    public function getEntityField($table, $column)
    {
        // dopsat automatickou konverzi ala bank_number -> bankNumber
        // vhodná inspirace viz výše
    }

    public function getTableByRepositoryClass($repositoryClass)
    {
        // dopsat automatickou konverzi ala Model\Repository\DeliveryTypeRepository -> delivery_type
        // tohle není nezbytně nutné, ale pak se lze kompletně vyhnout používání @table nad repositáři
    }

}

Pevně věřím, že je z této kostry jasné, co mám na mysli. Pak se Ti s Lean Mapperem bude pracovat maximálně pohodlně. Explicitně uvádět sloupce budeš muset pouze u případů, které se vymykají uvedeným pravidlům. Nicméně i řada specifik se dá zanést do Mapperu. Fakticky je doupřesnění sloupce (vazebního) v entitě nutné pouze v případě, že pod pokličkou máš z nějaké tabulky více vazeb 1:N do jedné jiné tabulky (aplikace má autor a správce atp.).

Mapper a jeho možnosti ještě nejsou zdokumentované. Plánuji připravit i příklad, který by pokryl podobné konvence, jaké máš Ty.

ad 3) Ten parser budu upravovat a bude vůči tomuhle imunnější. Tebou uvedené mezery už mu nebudou vadit. Rozhodně nejde o Tvou demenci – nejsi totiž první, kdo s tímhle měl problém. :) Každopádně mezera mezi názvem položky a upřesněním sloupce být musí, protože jinak by IDE špatně napovídala.

Kdybys narazil na jakýkoliv problém/dotaz, neváhej se zeptat. Vítám, že s každým novým uživatelem přichází zase nový pohled na věc a nové požadavky.

Editoval Tharos (16. 7. 2013 23:02)

Tharos wrote: Není to vůbec triviální záležitost (hlavně kvůli IN).

Víš, že pokud je např. složený PK přes sloupce foo a bar, tak lze napsat např.

WHERE (foo, bar) IN ((1, 2), (1, 3))

@Šaman: V aktuální develop verzi to ten sloupec už zase vrací. :) Zkus prosím provést update (jsem skalně přesvědčen, že tohle chování už se nebude měnit). Ve verzi, kde to v takovém případě vracelo NULL, je nutné jít pro ten sloupec do $property->getRelationship()->getColumnReferencingTargetTable() (pokud bys nechtěl/nemohl aktualizovat na aktuální develop verzi).

Nad tou poslední verzí je optimální řešení Tvého problému následující kód:

class BaseEntity extends \LeanMapper\Entity
{

    function __set($name, $value)
    {
        $property = $this->getCurrentReflection()->getEntityProperty($name);
        $relationship = $property->getRelationship();
        if (($relationship instanceof Relationship\HasOne) and !($value instanceof Entity)) {
            $column = $property->getColumn();
            $this->row->$column = $value;
            $this->row->cleanReferencedRowsCache($relationship->getTargetTable(), $column);
        } else {
            parent::__set($name, $value);
        }
    }

}

Volání getCurrentReflection() namísto getReflection() je jen drobná výkonnostní optimalizace. Smysl podle mě dává kontrolovat, že se jedná o hasOne vazbu, protože pro jinou tohle celé nemá smysl.

Čistit tu cache ručně je pořád bohužel nutné. Lean Mapper už může mít načtenou sadu souvisejících entit, ve které ale může chybět entita s ID, které se přiřadilo. Důvod, proč tohle nelze jednoduše detekovat přímo v Row (posléze v Result) je ten, že tyhle třídy už nemají znalost nadefinovaných vazeb. Ony už přímo neví, že když se zapíše do author_id, tak že to je sloupec reprezentující vazbu… Ještě ale promyslím, jestli by to přece jenom nešlo nějak hezky řešit.

Editoval Tharos (17. 7. 2013 9:12)

@Tharos docela bych uvítal možnost provádět akce po insertu/create

Narážím opět na closure table a vložení prvku do closury viz

INSERT INTO category_closure (ancestor, descendant, depth) VALUES (11,11,0); -- 11 je id nového prvku

INSERT INTO category_closure (ancestor,descendant, depth)
SELECT ancestor, 11, depth+1 FROM category_closure
WHERE descendant = 1; -- 1 je id rodice

do tvé aktuální verze 1.4 jsem si přidal jednu metodu afterCreate(Entity $entity), kterou volám po nastavení ID entitě v metodě persist. V poděděné afterCreate pak u konkrétního repozitáře provádím ty další 2 inserty. Chtělo by to minimálně přidat tohle anebo nějaký event, který bych si tam mohl přidávat callbackem via Nette\Object a property $on*

@Tharos spíš bych to viděl na Nette-way (tak jako u Nette\Object potazmo formularu)

Měl bys tam několik defaultních „callback-properties“ např. $onCreate, $onPersist, $onUpdate či $onDelete případně s prefixy before a after a jen bys registroval callback

// inside custom repository
$this->onAfterCreate[] = $this->addClosure($parentID);
//$this->onAfterCreate[] = Callback('addClosure', $parentID);

//...

function addClosure(Entity $entity, $parentID) {...}

ale když píšu tento příspěvek, tak mě napadá… kde se ten první příkaz bude vůbec volat? Nebo ten tvůj addEvent()? Po každém vytvoření repozitáře explicitně volat registraci eventů mi přijde špatné. Spíš automaticky volat inicializační metodu repozitáře v konstruktoru, kde si všechny tyhle signály zaregistruje repozitář sám a to zcela automaticky. Na mě bude jen podědit tuhle metodu a patřičně upravit její tělo

Editoval castamir (17. 7. 2013 11:09)

@Tharos podobně bys to mohl řešit i třeba pro selekci dat u repozitáře (defacto filtr). Např u tabulky systémových zpráv defaultně řadím podle času odeslání, v jiné tabulce zase řadím podle něčeho jiného… a když už budou eventy, tak proč dělat ty base filtry jinak? Přes initEvents by toho mohlo jít udělat i víc právě ;-) ale ikdyby ne, tak i s tímhle se prozatím spokojím ;-)

Edit: myslel jsem něco jako $onSelect[]

Editoval castamir (17. 7. 2013 12:48)

Když už jsme u toho offtopic, tak „entita“ a „pytel dat vyblitých z databáze“ neznamená totéž (i když se to často nesprávně zaměňuje). Normálně bych do toho nerýpal, ale když jsi zmínil že to budeš učit, tak by bylo dobré na tohle studenty upozornit.

Editoval mkoubik (17. 7. 2013 17:19)

@mkoubik: Vím, moje první setkání s modelem byl matematický model nějaké fyzikální soustavy, tedy cosi, co s ORM, pětivrstvým modelem pro práci s databází a vůbec s úložištěm nemělo žádnou souvislost.
Ale u studentů (máme spíš cvičení než přednášky) budu rád, když si zapamatují, že ten pytel dat si může některé své interní záležitosti obstarávat sám. A že je to plnohodnotná třída, ne jen obálka.
Druhý problém, když tohle pochopí, je přesvědčit je, aby nestrkali do entity externí funkcionalitu – typicky hned začnou vytvářet ActiveRow apod. :D

@Casper: Jsem na stopě. Single table inheritance bude potřebovat ještě kosmetický zásah do repositáře.

Měl bys kousek kódu, na kterém bych to mohl hned začít ladit? Pokud ne, nevadí, vyrobím si ho sám (už tuším, kde je problém).

Díky za report!

Šaman napsal(a):

@Tharos:

1. Mohla by být ta funkce $entity->getEnumValues() statická? Přece defacto vrací seznam statických konstant a používat se bude hlavně v selectech, kde nechci vytvářet instanci jen pro to, abych z ní načetl třídní konstanty. Díky.

To není žádný problém, můžeš si ji napsat jako statickou:

public static function getEnumValues($propertyName, IMapper $mapper = null)
{
    $property = self::getReflection($mapper)->getEntityProperty($propertyName);
    if (!$property->containsEnumeration()) {
        throw new InvalidArgumentException;
    }
    return $property->getEnumValues();
}

Tahle metoda není přímo součástí LeanMapper\Entity. Nechce se mi něco podobného zadrátovat přímo do jádra, protože se snažím, aby základní rozhraní entity moc nenakynulo. A tohle není metoda, kterou by využil úplně každý…

2. Poprosím, jestli bys přidal odkaz na GitHub do download sekce, protože (nevím proč už po několikáté) hledám tento odkaz na webu LeanMapperu pokaždé, když chci stáhnout novou dev verzi.

Máš ho tam. :)

Offotpic: Jestli do konce prázdnin bude stable verze s dokumentací…

No tak do konce prázdnin určitě bude. To je moře času. :) Vývoj i podpora mě hodně baví a to je myslím základ.

@Tharos možná by bylo fajn udělat nějaký rozcestník na problémy a jejich řešení zde na foru (zda jsou stále aktuální)

@Casper: Už mě to jednou taky napadlo… Mám s tím mírné dilema.

Ona se aktuálně ta entita neuloží, protože tomu zabrání databáze. :) Pokud někdo má v entitě sloupec, který není nullable, a persistuje jej do nullable sloupce v databázi, z mého pohledu má chybně navrženou databázi.

Jenomže je tu spousta ale… Sloupec v databázi může být nullable z nějakých zpětně kompatibilních důvodů, položka entity nemusí odpovídat nějakému jednomu sloupci… napadá mě toho řada.

Suma sumárum tu kontrolu možná zavedu. Přinese to i pár komplikací – já třeba s oblibou používám defaultní hodnoty v databázi pro sloupce s logickými hodnotami a to tedy budu muset ještě jednou dublovat… Ale výhody (větší robustnost) to asi převáží.

Díky za tip!

Bolo by mozne do 1.5 vtesnat aj udalosti? :) Kludne aj klasickym Nette style (onSomething) s podporou zakladnych eventov – onInsert, onUpdate, onPersist, onDelete (prip. ich varianty s after a before)

Opět jsem narazil na ten rozpor property v anotaci + set/get metody. Tentokrát jsem chtěl upravit jen setter (složitější kontrola dat), ale getter bych rád nechal. Mě připadá skutečně nejlepší řešení když metoda má přednost před defaultním chováním v anotaci. Nevím, jak ostatní, ale já jsem na toto chování docela navyklý a LM mě trochu mate. (Navíc se tím sjednotí volání $entity->foo a $entity->getFoo(), jejichž rozdílnost je občas wtf.)

A co se týče enumu – to zpracování konstant je originální, ale spíš bych ho viděl v nějaké Base třídě, než v jádru. Zato by se mi často hodilo, kdyby bylo možné předat enumům pole (jako property, i (hlavně) jako metodu).
Teď si LM vytváří to pole samo jediným možným způsobem (z konstant), což mi přijde těžkopádné a já si v některých případech musím kontrolu složitějších výčtů hlídat sám (proto chci přetížit setter).

Editoval Šaman (18. 7. 2013 18:04)

No, ve chvíli, kdy se ti něco objeví i v anotaci i jako metoda, tak se LM bude chovat při volání ->foo a ->getFoo() odlišně. Pokud by vždy dával přednost metodě před anotací, tak to bude konzistentní.

Pokud budu důsledně dodržovat buď jednu, nebo druhou možnost, problém nenastane ať se to bude chovat postaru, nebo jak navrhuji.

A mít jednu věc zapsanou pomocí metod i anotací mi jako chyba nepřijde. Jen logicky očekávám, že metoda se vykoná a anotace je jen dokumentační (protože magie). A ručně napsaná metoda by měla mít před magií přednost.
HintOnly tento problém sice vyřeší, ale pořád je to break proti konvencím všech ostatních tříd. S Nette to souvisí jen málo, konkrétně tím překladem property na metodu. Ale pokud bych jinde definoval magické settery a gettery, tak jejich explicitním naprogramováním se ty magické ‚vypnou‘. A tady ne.

Doufám, že jsem se v tomto kostbatém textu vyjádřil srozumitelně :)

S tím enumem je sice fakt, že to půjde pořešit pomocí passthru, ale že by enum takto magicky zpracovával konstanty mi stále připadá divné. :

<?php

// intuitivně bych nejprve zkusil toto
/**
 * @property string $month m:enum(['leden', 'unor', 'brezen'])
 */

// nebo něco takového
/**
 * @property string $month m:enum(self::$months)
 * @property string $month m:enum($this->getMonths())
 */
?>

To vytváření pole z konstant se může hodit, ale považuji to za dost specifickou věc.

Někde jsem zahlédl anotaci @inheritdoc, ta ale má fungovat trochu jinak, než jak ji používáš ty. Nutno dodat, že v NetBeansech mi to nefunguje ani tak, jak je popsané.
Ale hlavní je, že:

<?php

// tohle nebude napovídat (NetBeans),
// resp. napovídá prázdný název i popis i parametry.
/**
 * @inheritdoc
 */
function Foo()
{...}

// tohle zdědí kompletní nápovědu od předka, je-li nějaká.
// To samé i kdyby tam nebyla vůbec žádná anotace.
// Já to tak píšu jen abych věděl, že sem už jiná dokumentace nepatří. Ale není to pravá anotace.
/*
 * @inheritdoc
 */
function Bar()
{...}
?>

Editoval Šaman (18. 7. 2013 21:56)

Casper napsal(a):

@Tharos:

1. Co se týče rozdílného chování $entity->foo a $entity->getFoo(), taky jsem při přidávání specifických metod ponechal anotaci a divil se, že to neběhá – takže trochu wtf. Nicméně jsem v tomto fóru minul flag m:hintOnly a s ním už to imho smysl dává.
2. S těmi neúplnými entitami nevím jestli jsme se pochopili. Pokud mám rozdílnou definici nullable atributů/sloupců v db a entitě, je to samozřejmě špatně. Šlo mi však především o to, že mohu jako programátor zapomenout vyplnit některé (ne-nullable) atributy entity a LM jí i přesto uloží do db, která tam vyplní defaultní hodnoty (pro VARCHAR například prázdný řetězec). A od téhle chyby by mě ORM mohlo (mělo?) odradit, pokud má být robustní. Aneb pokud mám v entitě atribut, který není nullable (alias NOT NULL sloupec v db), měl by být při perzistenci vyplněn.
3. Taktéž zkus zvážit variabilnější metodu getData (popřípadě jinou, něco jako getPreviewData). Často (defaultní data formuláře, výpis do tabulky, uložení dat uživatele do session (Identity)) potřebuji získat „základní“ data entity bez vazeb, tedy bez (kolekcí) navázaných entit, kterých může být hodně. Aneb při těchto použitích, kdy potřebuji surová vlastní data entity, kdy mě nezajímají vazby na ostatní objekty, je zbytečné se na ně dotazovat do databáze. Je zřejmé, že by nebylo vhodné vytvořit tuto funkcionalitu natvrdo jak píšu, ale spíše nějakým způsobem mít možnost ovlivnit jaké hodnoty mi getData vrátí a jaké už ne. Implementací je mnoho (whitelist, blacklist, pomocná protected metoda pro rozhodnutí, zda atribut zahrnout či ne, …). Osobně jsem si již něco takového implementoval a využívám to poměrně často.

3. Nepostaci ti metoda getRowData()?

A ještě detail. Je nějaký zásadní důvod, proč metody typu beforeCreate dostávají jako argument pole modifiedData a nikoli celou entitu (krom toho, že repozitář v těchto nízkoúrovňových operacích většinou pracuje s nízkoúrovňovými daty)?

Pokud totiž například potřebuji při ukládání entity vygenerovat hodnotu nějakého sloupce na základě hodnot vazebních entity, musím poměrně složitě tyto entity hledat – musím mít závislost na cizích repozitářích a na základě vazebních atributů je manuálně dotahovat (případně se dotazovat přímo do db). Pokud bych měl přístup k celé entitě, bude to jedno prosté volání.

Aneb brání něco tomu, aby tyto metody přijímaly $entity a bylo na programátorovi, co si z nich vytáhne? Metodu getModifiedRowData() si můžu zavolat vždycky.

Edit: teď mi došlo, že na můj problém bylo asi bylo vhodnější využít plánovaných defaultních hodnot, nicméně odpověď na dotaz mě zajímá i tak :)

Editoval Casper (19. 7. 2013 12:06)

Ahoj, narážím na nefunkční isset() nad jednotlivými property entity.
Příklad:

/**
* @property int $id
* @property string|null $title
* @property bool $status
*/
class Book extends BaseEntity {
}

a zkusím isset($entity->id), tak to taky nic nenajde.

Když si tuto entitu předám do šablony a používám makro {ifset $entity->id}, tak taky nic.
Samotný výpis $entity->id je ale v pořádku.

Konkrétně jsem na to narazil při spojení s NextrasGridem.
NextrasGrid kontroluje u entity řádku, zda obsahuje property potřebnou pro výpis daného sloupce https://github.com/…Datagrid.php#L328 a používá k tomu funkci isset. Getter jsem si pomocí callbacku přepsal ($row->getCurrentReflection()->getEntityProperty($column) přičemž getCurrentReflection jsem si prasácky podědil jako public fci ), ale vzápětí jsem na to narazil i v latte.

Dalo by se s tim něco dělat?

něco na tento způsob by nešlo?

// BaseEntity
function __isset($key) {
    return isset($this->__get(key));
}