Lean Mapper – tenké ORM nad dibi

@jannek19: Ahoj, je více možností, jak tohle vyřešit. V MySQL databázi bych to já řešit asi tak, že bych měl ten sloupec nadefinovaný takto:

created DATETIME DEFAULT CURRENT_TIMESTAMP

Property bych pak měl read only a vůbec ji ručně nenastavoval. Bohužel výše uvedená definice funguje asi až od MySQL 5.6.5…

Jinak bych to asi řešil v repositáři přetížením protected metody Repository::insertIntoDatabase. Na entitě bych tu položku měl opět nadefinovanou jako read only a v té přetížené metodě v repositáři bych tu hodnotu doplňoval. V podstatě bych si tu miniaturní metodu (má 6 řádků) napsal pro relevantní typ entit nanovo.

@duke: Stále nosím v hlavě ten problém týkající se datumu 0000-00-00. Implicitní passThru by to řešit a vážně nad ním popřemýšlím, ale na co bys vůbec takový datum převáděl? Na 30. 11. –0001? Není to trochu „ujeté“?

V dokumentaci k MySQL píšou, mimo jiné, následující:

“Zero” date or time values used through Connector/ODBC are converted automatically to NULL because ODBC cannot handle such values.

A tak přemýšlím, jestli by nebylo nejlepší takové nesmyslné datum převádět na NULL (rovnou je vnímat jako NULL)…

Před nějakou dobou jsem začal používat LeanMapper a nemůžu si ho vynachválit. Řeším ale jeden problém, který nejsem schopný nějak doladit.

Mám entitu Product a další entitu a tabulku s obrázky, které jsou ke každému produktu přiřazeny. Pokud chci získat všechny obrázky, vše funguje jak má:

<?php
/**
 * @property-read int $id
 * @property User $author m:hasOne(user_id)
 * ...
 * @property-read ProductImage $representImage
 * ....
 * @property-read ProductImage[]|null $images m:belongsToMany
 */
class Product extends BaseEntity
{
}
?>

Problém ale mám, pokud chci získat jenom jeden „reprezentační“ obrázek, respektive obrázek jako náhled v nějakém menu. Napadlo mě připsat vnořený SELECT do repository, ale řekl bych, že jsou určitě efektivnější způsoby jak k danému SQL přidat vnořený SELECT, který by z tabulky s obrázky vybral pouze jeden a použil se jen v případě, kdy bych representImage volal, ovšem nevím si s tím moc rady, i když si říkám, že řešení musí být jednoduché.

Díky za radu :)

Omlouvám se, tabulky jsou 2

• Product (id, author_id, title…)
• Product_Image (id, product_id, filename, upload_date)

Jeden product má více obrázků a representImage by měl vracet právě jeden obrázek (filename), byť jich je několik (měl by sloužit jako náhled), teoreticky je i jedno který.

To SQL, co jsem zkoušel napsat v repositáři by mohlo vypadat nějak takto

<?php
        $row = $this->connection->select('*')
            ->select(
                $this->connection->select('[product_image.file_name]')->from('[product_image]')
                    ->where('[product_image.product_id] = ' . '[' . $this->getTable() . '.id]')
                    ->orderBy('[' . $this->getTable() . '.id]')
                    ->limit(1)
            )->as('representImage')
            ->from($this->getTable())
            ->where('id = %i', $id)
            ->fetch();
?>

Z toho je už snad i můj záměr patrný a takto to funguje, ale zdá se mi to hrozně špatně řešené.. Nejsem si ani jistý, jestli je návrh těch tabulek správný, vše se to snažím učit takto za chodu, díky za trpělivost.

Editoval majkl324 (9. 3. 2014 16:53)

@majkl324: Ještě castamira doplním. Pokud bys nechtěl načítat z úložiště při přístupu k tomu jednomu reprezentativnímu obrázku všechny ostatní, můžeš použít následující „strategii“:

/**
 * ...
 * @property ProductImage[] $images m:belongsToMany
 * @property-read ProductImage|null $representImage m:belongsToOne(#union)
 */
class Product extends BaseEntity
{

    public function getRepresentImage()
    {
        return $this->getValueByPropertyWithRelationship('representImage', new Filtering(function (Fluent $statement) {
            $statement->orderBy('rating')->desc()->limit(1);
        }));
    }

}

Takhle docílíš přesně toho, co potřebuješ, a jako bonus Lean Mapper vygeneruje hezké dotazy. V tom anonymním filtru jsem naznačil, že si můžeš za reprezentativní obrázek snadno vybrat třeba takový, který má nejlepší rating atp.

Edit: Ještě jsem kód opravil. :) Teď už by to mělo být správně…

Editoval Tharos (9. 3. 2014 20:15)

@EIFEL: Je to dokonalá analogie výše uvedené záležitosti. :)

Nejsnáze (na počet řádků) to lze zhruba takto:

/**
 * ...
 * @property-read ProductPrice|null $actualPrice m:belongsToOne(#union)
 */
class Product extends BaseEntity
{

    public function getActualPrice()
    {
        return $this->getValueByPropertyWithRelationship('actualPrice', new Filtering(function (Fluent $statement) {
            $statement->orderBy('date')->desc()->limit(1);
        }));
    }

}

Píšu to úplně z hlavy, ale mělo by to fungovat. Kdyžtak mi to reklamuj. :)

janpecha napsal(a):

Ahoj, protože už mě fakt nebaví prohrabávat toto vlákno, tak jsem si dneska začal psát takovou vlastní „dokumentaci“ k LeanMapperu. Prozatím je to stále ve stádiu tvorby, hotová je základní podoba webu, samotná dokumentace obsahuje nyní pouze základní odkazy na stažení jednotlivých verzí, API dokumentace a odkazy na některá rozšíření. Postupně chci doplnit informace o entitách (základy, možnosti a přehled anotací, …), repozitářích, rady a postupy, co tu kdo publikoval, apod.

Pokud by měl někdo zájem zapojit se, budu rád, kompletní obsah je na GitHubu. Samotný web pak zde.

Je skvělé, že máš vůli pomoct s dokumentací!

Popravdě jsi mě svým přispěním trochu nakopl, protože by nebylo optimální, kdyby se nám dokumentace příliš roztříštila. Chápu, že svou pomalostí tomu dost nahrávám, ale právě jsi mě trochu popohnal. :)

Přes víkend jsem „hodil na papír“ (GitHub) to, jakou by dokumentace mohla mít optimálně strukturu, a podle toho jsem předpřipravil Wiki na GitHubu. Jsem pro použít GitHubovou Wiki, minimálně pro sepsání první verze kompletní dokumentace.

Zítra budu trávit část dne ve vlaku, a tak se zavazuji, že doplním obsah této stránky a pokusím se třeba i nějak více „vykopnout míč“.

@EIFEL: Jakmile dokončím tu „infrastrukturu“ kolem Wiki, tak novou stable verzi vydám. Takže nejspíš někdy v průběhu tohoto týdne.

@EIFEL: Dokázal bys mi to na nějakém minimálním příkladě předvést? Zní to jako docela haluz. :) Nenapadá mě, jak by se tam nějaký presenter mohl dostat…

Zdravim,

potreboval bych natuknout smer, jak resit nasledujici:
Mam 3 entity: dilo, verze, zaznam
Dilo je zakladni, z nej vazba hasmany do verze, z nej vazba hasmany do zaznam.

Priklad: Dilo je „Pan Prstenu“ (autor, datum vydani), verze je „kniha/film/komiks“ (nakladatelstvi, id. cislo), zaznam je „ABC“ (ev. cislo, fyzicke umisteni).

Vytvarim vyhledavaci formular, do ktereho si uzivatel muze zadat vyhledavaci parametry ze vsech tri entit a dostane seznam „zaznamu“ vyfiltrovanych podle zadaneho nastaveni formulare. Jak na to, abych co nejefektivneji vyuzil LM a DB? Udelat si filtrovani nad „Dilo“ a pote si pres foreach na „verzi“ a nasledne foreach na „zaznam“ upravovat vyslednou kolekci (unsetovat „dilo“) a pak vypisovat ze zbytku? Jak pak zajistit treba sortovani podle sloupcu ze „zaznam“?
Nebo si napsat dotaz na urovni dibi a prijit tak o vyhody orm?

Editoval elden46 (10. 3. 2014 13:13)

castamir, Tharos, díky moc za radu, vše funguje :)

@tomas.lang: Co se testování týče, nemusí se na toho obra až tak složitě. :) Není zapotřebí mockovat přímo dibi driver.

Všimni si, že entity na nízké úrovni pracují pouze s Row. Connection je v něm velmi důsledně zapouzdřené. A proto stačí vytvořit mock (stub) pouze pro Row.

Zde je malá ochutnávka:

/**
 * @property int $id
 * @property string $name
 * @property Book[] $books m:belongsToMany
 */
class Author extends Entity
{
}

/**
 * @property int $id
 * @property string $name m:passThru(emphase)
 */
class Book extends Entity
{

    protected function emphase($value)
    {
        return strtoupper($value);
    }

}

class RowMock extends Row
{

    private $mapper;

    private $data;


    public function __construct(IMapper $mapper, array $data = array())
    {
        $this->mapper = $mapper;
        $this->data = $data;
    }

    public function isDetached()
    {
        return false;
    }

    public function getMapper()
    {
        return $this->mapper;
    }

    public function setConnection(Connection $connection)
    {
    }

    public function hasConnection()
    {
        return true;
    }

    public function __set($name, $value)
    {
        $this->data[$name] = $value;
    }

    public function __get($name)
    {
        return $this->data[$name];
    }

    public function referencing($table, $viaColumn = null, Filtering $filtering = null, $strategy = null)
    {
        if ($table === 'book') {
            $rows = [];
            $data = [
                ['id' => 1, 'name' => 'First book'],
                ['id' => 2, 'name' => 'Second book'],
            ];
            foreach ($data as $entry) {
                $rows[] = new RowMock($this->mapper, $entry);
            }
            return $rows;
        }
    }

}

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

$connection = new Connection([ // fake!
    'lazy' => true,
]);

$author = new Author(new RowMock($mapper));
$author->makeAlive($entityFactory, $connection, $mapper);

$author->name = 'John Doe';

echo $author->name, "\n";

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

Ukázka vypíše následující:

John Doe
- FIRST BOOK
- SECOND BOOK

Je to takhle pro Tebe použitelné? Anebo by sis to představoval ještě nějak lepší?

Editoval Tharos (11. 3. 2014 0:14)

Střelba od boku – zkoušel jsi typ array|string?

@Šaman Ne, to opravdu nefunguje. Takovéto míchání typů v anotaci LeanMapper vůbec nepodporuje.

Zatím jsem to vyřešil tak, že jsem tam nechal typ string[] a zakomentoval tu kontrolu v Entity.php, která při __set vyhazuje výjimku, neboť zjevně se tam nebere v potaz to, že passThru setter může změnit hodnotu z deklarovaného pole na skalár.

Ahoj přátelé,

tak dokumentační Wiki je plně připravená.

Kdo tedy máte chuť přiložit ruku k dílu, vítejte na palubě. :) Sám se pustím do migrace obsahů, které mám rozpracované v tomto repositáři a také u sebe na disku.

Případní přispěvovatelé, určitě nepřehlédněte stránku o tom, jak přispívat.

Díky za pozornost a spolupráci!

Tharos napsal:

@duke: Skutečně to byla chyba. Typ přiřazované hodnoty se kontroloval na nízké úrovni i při použití passThru, což je samozřejmě nežádoucí.

Mohl bys prosím ověřit verzi dev-hotfix/passThru? Kdybys nejel přes Composer, pushnul jsem tu větev i na GitHub…

Tak jsem to otestoval a pokud zvolím anotaci:

* @property array     $roles m:passThru(decodeRoles|encodeRoles)

… tak to, zdá se, funguje dobře.

Pokud zvolím typ string[] nebo string, chová se to stejně jako před tím. Tj. pro typ string[] to stále kontroluje typ přiřazené hodnoty na nízké urovni i při použití passThru a vyhodí výjimku.
Mám za to, že anotace s typem string[] by měla fungovat…

@duke: Aktuálně Lean Mapper zápisy typu string[] nepodporuje. [] lze použít pouze u objektů.

Já osobně to u skalárních hodnot totiž považuji tak trochu za zbytné. Hlavní výhodu zápisu Book[] $books vidím v tom, že kdy pak iteruji nad $books, IDE mi pro každou knihu napovídá její property. Z tohohle pohledu zápis string[] nemá žádný přínos oproti array.

No a co se validace dat týče… Ona už teď není kdo ví jak důkladná. Mám dojem, že se kontroluje jenom první hodnota. Přínos je spíš takový, že hned zjistíš, když vytvoříš kolekci nějakých úplně špatných typů. Kontrolovat úplně všechny hodnoty se mi nechce z výkonnostního hlediska… U velkých kolekcí se každý průchod počítá.

Takže ten fix z mého pohledu funguje. U passThru se předpokládá, že type hint bude takový, jaká bude hodnota v PHP. V Tvém případě tedy array.

Tharos napsal:

@duke: Aktuálně Lean Mapper zápisy typu string[] nepodporuje. [] lze použít pouze u objektů.

Já osobně to u skalárních hodnot totiž považuji tak trochu za zbytné. Hlavní výhodu zápisu Book[] $books vidím v tom, že kdy pak iteruji nad $books, IDE mi pro každou knihu napovídá její property. Z tohohle pohledu zápis string[] nemá žádný přínos oproti array.

Rozumím tomu, že z hlediska napovídání IDE v tom nemusí být žádný přínos. Přesto si myslím, že by to LeanMapper mohl umět (to, že to lze použít jen u objektů a u jiných typů ne, je trochu WTF). A pokud to neumí, měl by alespoň vyhazovat výjimku už při zpracování takových anotací (případně s doporučením: use „array“ as type). Výjimka, kterou to vyhazuje teď, je zavádějící.

No a co se validace dat týče… Ona už teď není kdo ví jak důkladná. Mám dojem, že se kontroluje jenom první hodnota. Přínos je spíš takový, že hned zjistíš, když vytvoříš kolekci nějakých úplně špatných typů. Kontrolovat úplně všechny hodnoty se mi nechce z výkonnostního hlediska… U velkých kolekcí se každý průchod počítá.

Jedna věc je kvantita (validace celé kolekce vs jen prvního prvku; napadá mě také možnost líné validace pokud by se pracovalo s nějakým iterátorem, či volitelná validace, kterou by šlo např. aktivovat jen ve vývojovém režimu, atp.) a druhá věc je kvalita (validují se všechny typy polí vs validují se jen pole objektů; zde nevidím důvod omezovat se jen na pole objektů).

Takže ten fix z mého pohledu funguje. U passThru se předpokládá, že type hint bude takový, jaká bude hodnota v PHP. V Tvém případě tedy array.

Pro anotaci array už opravdu funguje a za tuto rychlou opravu děkuji.

@Šaman to už se tu někde řešilo… DBAL z docrine se dá použít i v LM…

Nedávno jsem narazil na jeden blogpost o přechodu z NDBT na Doctrine a docela jsem se zhrozil z podoby entity. Krom tvých nedostatků bych přidal ještě nutnost duplikovat datový typ v anotaci…

@Šaman: https://forum.dibiphp.com/…orm-nad-dibi?p=20

Ahoj,

mile rád bych odlehčil tomuhle dloouhému vláknu a napadlo mě, že bychom mohli významnou část diskuze dále vést na GitHubu v issues.

Issues, jak asi nikoho nepřekvapí, nejsou jenom o chybách. Vytvořil jsem následující sadu štítků:

• Approwed feature
• Bug
• Duplicate
• Question
• RFC
• Wiki

Když je budeme používat, tak by mělo být možné na GitHubu řešit vše mnohem přehledněji – od dotazů přes RFCčka až po bugy.

Vím, že j zapojení se je zapotřebí mít účet na GitHubu, ale to je myslím malicherná vstupní bariéra.

Díky za pozornost. :)

Editoval Tharos (16. 3. 2014 21:56)

@EIFEL jedním z mnoha způsobů (vím o 4), jak to řešit, je použití closure tables. Můj blog, kde popisuju jejich použití, je sice teď vypnutý, ale alespoň odkážu na podobný článek: http://blog.voracek.net/…rochu-jinak/

Předem však upozorňuji na drobné nedostatky v uvedených sql – ověř si, zda doopravdy dělají to, co chceš.

Ahoj, mám menší dotaz:

Pokud mám anotaci m:belongsToMany, dá se nějak upravit pořadí, v jakém se vrátí ty entity? Dá se to nějak udělat na úrovni SQL nebo musím pomocí m:passThru prohodit to pole nějakým usortem?

Editoval greeny (25. 3. 2014 9:54)

@Tharos – jo, já si totiž moc nečetl ty posty nad tím, všiml jsem si toho až po odeslání dotazu ;) Díky

Editoval greeny (25. 3. 2014 11:41)

@johnson: Mělo by to jít velmi jednoduše. V repositáři se stačí někde před vytvořením entity podívat do databáze, jestli už taková entita existuje, a pokud ano, můžeš tu do repositáře předanou na tu existující „napojit“ pomocí metody Entity::attach.

Asi bych pak ještě zkontroloval, jestli v té předané nebyly pozměněny nějaké hodnoty, které bych kdyžtak v úložišti také aktualizoval…

Anebo by mělo jít použít v repositáři konstrukci INSERT ... ON DUPLICATE KEY UPDATE. To by bylo asi ještě lepší, čistější řešení. :)

Stačí Ti takhle rámcové navedení? Pokud ne, můžeme to probrat ještě na GitHubu v issues. Díky!