Lean Mapper – tenké ORM nad dibi

@Šaman: To, co popisuješ, bych osobně řešil tak, že bych si vytvořil nějaká MapperExtension rozšíření. Ta bych pak do hlavního Mapperu registroval obdobně, jako se registrují například extenze do Nette konfigurátoru před sestavením DI kontejneru. Určitě by šlo udělat, aby se to odehrálo úplně automaticky: jakmile bys nějakou takovou extenzi zaregistroval jako službu do DI kontejneru, kontejner by ve vhodný okamžik mohl projít všechny MapperExtension, které obsahuje, a zaregistrovat je do hlavního Mapperu.

Jak jsem psal, Mapper se předává při traverzování mezi entitami a byl by neudržitelný hokej, kdyby jich bylo víc (těch Mapperů) a každý by tvrdil třeba něco trochu jiného. Je to jako kdybys pracoval s více DibiConnection zároveň, každé jsi měl připojené do jiné databáze a snažil se z toho celého uvařit nějaký konzistentní výsledek. (Lepší analogie mě nenapadla :–P.)

Editoval Tharos (29. 1. 2014 16:57)

Zdravim :)

Uz par dni sa hram s generovanim tabuliek v databaze pomocou entit z LeanMapperu. Objavil som pomerne silnu funkciu Doctrine – schemy (http://docs.doctrine-project.org/…ntation.html). Pomocou tohto je generovanie tabuliek naozaj hrackou :)

Tu je moj nastrel – https://gist.github.com/…mous/8782935

Samozrejma je aj implementacia vazieb, cudzich klucov, vlastne flagy (m:size, m:autoincrement, m:unique, m:format(date|time) pri DateTime).

Daju sa s tym urobit hotove zazraky, mozete si ukladat stare schemy a pri zmene entity vam to moze vygenerovat potrebne SQL na zmenu databazy. Tu je priklad – https://gist.github.com/…mous/8782990 :)

Uvitam akekolvek pripomienky a napady :)

Dakujem :)

Tiez som to chcel pisat vsetko rucne a odznova… ale potom som na jednom projekte zacal pouzivat schemy, kde som si vsetko rucne definoval (kazdy stlpec, vazbu) a ked som mal to iste pisat aj do entity, tak som si povedal ze tu musi byt aj ina cesta.

Osobne sa mi paci mat zapisane metadata priamo v entitach, nejako mi to tam proste pasuje. Je sice pravda, ze po case to moze nabobtat, ale to by muselo ist o uber-entity :)

Nad generovanim formularov som premyslal, no narazil som na jeden zasadny problem – ak by som chcel vytvorit HasOne a HasMany vazby, musim mat dostupne repository k danej vazbe. Napr. mam entitu Product a ta ma HasOne na Category. Otazka ale znie, ako sa mozem vo formulari dostat ku CategoryRepository alebo k niecomu podobnemu? Musela by tam byt nejaka RepositoryMap, kde by bola trieda entity a k nej patricke repository, aby som sa mohol k tym entitam vo formulari dostat… Otazkou je, ze ci je to spravny pristup :)

Ahoj,

právě jsem začal používat tento výtečný nástroj…Jen mi zaboha nefunguje ukládání datetime.

<?php
$x->inserted = new \DateTime();
?>

persistuji a:

Unexpected value type given in property ‚inserted‘ in entity Model\Entity\Phrase, Model\Entity\DateTime expected, instance of DateTime given.

děkuji za radu

Ahoj vespolek,

tak nějak se rozkoukávám v Lean Mapperu a zatím se mi to moc líbí! Můj zatím jedinej „teologickej“ problém s LM je, že je to striktně databázová vrstva, což je podle mě podmnožina toho, co by měl model v tom nejširším pojetí umět.. nejsem nijak velkej odborník na ostatní ORM ani na návrhové vzory obecně, ale pocitově bych řekl, že má-li model zapouzdřovat obecně všechnu práci související s perzistentními daty a vztahy mezi nimi, patří mezi tyhle data třeba i některé obrázky (dokonce někdy zejména obrázky), nebo obecně vzato věci, které chceme spíš uložit do souboru. Pokud pomineme možnost ukládat obrázky do BLOB sloupců v databázi (uf, úplně mi vstávaj vlasy na zátylku), žádná striktně databázová modelová vrstva nám tuhle možnost nedá.

Takže se chci zeptat, jak tohle řešit konkrétně u Lean Mapperu? Rád bych bral LM jako tu modelovou vrstvu, obalovat ho ještě něčím zvenku mě neláká. Ale třeba konkrétní příklad obrázkové galerie: jednoduchá tabulka pictures (id INT, postedOn DATETIME, description TEXT) a někde odpovídající adresář pictures, ve kterém čekáme JPEGy pojmenované <id>.jpg. Až na ten soubor je to celkem pěkná entita.. ale jakmile začnu přemejšlet o tom, že ta entita vlastně popisuje soubor a nějaká jeho metadata, začnu mít divný otázky a nemít na ně odpověď:

• Jak taková entita má vzniknout? Řekněme, že uploaduju novej obrázek. Vzniká entita. Moje představa je taková, že bych entitě asi měl předat nějakou cestu (třeba $upload->getTemporaryFile()) a entita (respektive její repository) by si před perzistováním měla uvědomit, že má tenhle soubor odcestovat na patřičné místo a cestu si aktualizovat. Dobře, to by nebyl takovej problém (pomocí eventů atp).
• Zároveň ale – nejsou binární data obrázku tak trochu „náplní“ (smyslem) téhle entity – a neměly by tudíž bejt skrze ni nějak dostupný? nebo třeba instance Nette\Image? Protože jinak práci s binárními daty vyčleňuji ven z modelu (pro ten bude property filename prostě jen string bez hlubšího významu).. kdo pak obrázky zmenší? ořízne? obrátí vzhůru nohama? atd.

Jak prostě zařídit, aby mi tahle část doménové logiky (ha, termitus technikus!) nezmizela z modelu a nezačala se, nikým nezvaná, objevovat někde, kde ji nechci?

Etch napsal(a):

Já teda nevím „školy nemaje“, ale neslouží ORM už z podstaty k mapování dat z RDBMS??

Já právě také školy nemaje čtu „Object Relational Mapping“ doslovně, tedy jako „vztahovou mapu objektů“ – v čemž mi „databáze“ nutně nerezonuje. Není snad obrázek ve fotogalerii objektem, který má nějaké vlastnosti a nějaké vazby na okolní svět?

Přijde mi „nesprávné“ chápat samotné ORM jako „modelovou vrstvu“.

K chápání ORM jako ucelené modelové vrstvy mě vede to, že už pracuje s těmi objekty, které mě zajímají – tj s entitami a jejich vztahy, nějak úplně objektově nevidím, kde by tam měla být další vrstva.

Co znamená „obalovat ho ještě něčím z venku“? Je vytvoření třeba nějaké FACADE pro tebe obalování?

Vytvoření fasády bezesporu obalováním je :-) minimálně ve smyslu „zapouzdření“. Může to samozřejmě mít svůj smysl, ale ten podle mě u facade patternu spočívá především v definování API nezávislého na spodní vrstvě fasády, případně ke spojení API a odpovídající funkcionality rozložené do více služeb / nástrojů v jeden, pokud to má smysl. Ale pořád se mi vnitřně ta entita „obrázek“ nechce rozpadnout na „metadata entitu“ a „binární data obrázku“ sjednocené pod jednou fasádou.. představ si stejnou situaci u článku: „článek“ jako takovej je nepochybně ten samotnej text, kterej je v databázi uloženej ve sloupci typu TEXT, všechno okolo (datum publikování, ID autora, …) jsou jen metadata. Měl by „článek“ bejt vlastně jen fasáda nad entitou „metadata článku“ a nějakou jinou položkou „článek“? To by nedávalo po žádný stránce smysl. Tak proč by to u obrázku (nebo obecně objektu, kterej nechceme ukládat do databáze) mělo bejt nutně jinak, když problém je jenom se samotnou „storage“ vrstvou?

To zní, jako kdyby si naznačoval, že co ti „zmizí“ z ORM, ti zmizí z modelu. Možná že se mýlím, ale tento způsob chápání ORM jako „celé“ modelové vrstvy, mi přijde jako poněkud „divná“ myšlenka.

No to právě viz výše. Když už celej ORM pracuje s entitama, což je pro mě osobně tak nějak to, s čím chci pracovat vně modelu, přijde mi nepřehledný a z pohledu objemu kódu / práce zbytečný obalovat každou jednotlivou entitu ještě nějakou fasádou (dělat to jen u jedný by nebylo konzistentní), abych zajistil funkci, která podle mě už tak nějak uvnitř tý stávající struktury má bejt..

Ale ať zas tak moc neteologizujem, nehádám se, že by Lean Mapper měl umět ukládat data kamkoliv a jakkoliv nebo že bych na něm obecně něco měnil, spíš mě jen zajímalo, jak se tohle podle konvencí Lean Mapperu správně řeší – tj. je nějaká cesta, jak Lean Mapper používat přímo jako modelovou vrstvu a pokud ano, kam a jak tedy patří zpracovávání takovéhohle typu dat? Nebo to prostě takhle být nemá a Lean Mapper má sloužit jen jako jedna ze „spodních vrstev“ Modelu s velkým M, kterej to má celý obalit?

A tady je další otázka z trochu jiného soudku: lokalizace. Ne, nekřičte, četl jsem tohle vlákno asi celé a vím, že se to řešilo. Mám na to řešení ale trochu větší nároky. Východisko je stejné: pro lokalizovanou entitu mám dvě tabulky, jednu s nepřekládaným obsahem a jednu navázanou přes cizí klíč s lokalizovanými variantami překládaného obsahu (tj. unique klíč nad entity_id, language_code). Jako vstupní parametr při nasosávání entity ale nemám jeden jazyk, nýbrž pole jazyků seřazených podle preferencí uživatele; výstupem má být entita, která tohle kritérium splňuje nejlíp, jak to jde.

Příklad: uživatel preferuje jazyky en, cs a de v tomhle pořadí. Článek má dostupné překlady pro cs, sk a ru. Vrácená entita tedy má být lokalizována do češtiny. Pokud by ovšem článek žádný z uživatelem preferovaných překladů neměl, měla by se vrátit entita lokalizovaná řekněme do první dostupné jazykové verze (takže třeba sk). Tohle umím jedním dotazem (je to trochu mysql magie, ale to mi pro můj use-case nevadí).

Jak mám ale s entitou pracovat v hypotetickém administračním rozhraní, kde admin v jednom formuláři může vytvářet překlady pro všechny webem podporované jazykové mutace? Formulář má část prvků pro nepřekládané property entity a pak má kontejnery s překladovými variantami. Najednou bych chtěl místo:

<?php
$entity->title = '..';
$entity->content = '..';
?>

použít něco jako:

<?php
foreach ($langs as $lang) {
    $entity->$lang->title = '...';
    $entity->$lang->content = '...';
}
?>

Ono by to teda asi nebylo takhle přímo na entitě, ale spíš v nějakém poli $entity->contents[$lang], ale jde o jinou věc – při čtení entity vůbec nemám žádné pole contents a místo něj mám property title, content …, naopak při zápisu nemám tyhle property a mám pole contents.. jak na to? :-)

Editoval danik (6. 2. 2014 3:14)

Pročítám toto forum a mám následující dotaz.

Jakým způsobem vyřešit následující problem:

Mám knihy a ty mají tagy. A rád bych dostal jen knihy, které tagy nemají.

Řeší se toto již v repository? Nebo to mohu „vyfiltrovat“ až po načtení entit? Čtu zde o filtrech, je to správné řešení?

Děkuji

@danik: ORM skutečně znamená objektově relační mapování.

Pokud bys chtěl mít data uložená nějak „hybridně“ (něco v relační databází, něco třeba v nějakém XML na disku, něco v nějakých souborech…), tak vše, co budeš potřebovat vyřešit, už za Tebe bohužel ORM nevyřeší. A nebude toho málo, hlavně bude pracné udržovat konzistenci dat (referenční integritu). Určitě se v takovém případě neobejdeš bez dalších vrstev nad nějakým ORM.

Nejen z výše uvedených důvodů se podobné problémy často řeší právě tak, že třeba i Tebou uvedené obrázky jsou „mapovány“ v relační databázi a na disku (nebo v nějaké CDN) se už jen udržují související binární data. Je to velmi výhodné a vcelku standardní řešení.

V Lean Mapperu není problém mít entitu Image, která bude mít například položku uri. Jelikož entity v Lean Mapperu mohou být „chytré“, není problém si do takové entity injektnout službu, jejíž zdopovědností bude formulování správného uri.

S ukládáním a následným managementem těch dat mimo relační databázi Ti ale Lean Mapper příliš nepomůže, Lean Mapper je prostě ORM. Může jít o velmi pestrou činnost (ukládání někam na disk vs. upload do CDN…) a je právě na programátorovi, aby tohle v rámci modelu elegantně vyřešil. :) Lean Mapper Ti jen vychází vstříc vcelku flexibilními repositáři, do kterých se lze snadno „nahookovoat“, anebo systémem událostí.

@batko: Luxusní požadavek, to tu ještě nebylo :).

Nad SQLite databází, která je součástí Lean Mapperových testů, bych to osobně řešil následovně:

/**
 * @property int $id
 * @property string $name
 * @property string $pubdate
 * @property-read Book|null $previous m:hasOne(previous)
 * @property-read Book|null $next m:hasOne(next)
 */
class Book extends \LeanMapper\Entity
{
}

class BookRepository extends \LeanMapper\Repository
{

    /**
     * @return Book[]
     */
    public function findAll()
    {
        return $this->createEntities(
            $this->createFluent()->fetchAll()
        );
    }

}

class Mapper extends DefaultMapper
{

    protected $defaultEntityNamespace = null;

    /** @var Connection */
    private $connection;


    /**
     * @param Connection $connection
     */
    public function __construct(Connection $connection)
    {
        $this->connection = $connection;
    }

    /**
     * @param string $entityClass
     * @param Caller $caller
     * @return mixed
     */
    public function getImplicitFilters($entityClass, Caller $caller = null)
    {
        if ($entityClass === 'Book') {
            return function (Fluent $fluent) {
                $fluent->select(
                    $this->connection->select('prevbook.id')->from('[book] [prevbook]')
                        ->where('[prevbook.id] < [book.id]')
                        ->orderBy('id')->desc()->limit(1)
                )->as('previous')
                ->select(
                    $this->connection->select('nextbook.id')->from('[book] [nextbook]')
                        ->where('[nextbook.id] > [book.id]')
                        ->orderBy('id')->limit(1)
                )->as('next');
            };
        }
        return parent::getImplicitFilters($entityClass, $caller);
    }

}

Připravíme-li si poté následující testovací skript:

$mapper = new Mapper($connection);

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

foreach ($bookRepository->findAll() as $book) {
    echo "[$book->id] $book->name\n";
    if (isset($book->previous)) {
        echo str_repeat(' ', 5) . "[{$book->previous->id}] {$book->previous->name}\n";
    }
    if (isset($book->next)) {
        echo str_repeat(' ', 5) . "[{$book->next->id}] {$book->next->name}\n";
    }
}

Dostaneme takovýto výstup:

[1] The Pragmatic Programmer
     [2] The Art of Computer Programming
[2] The Art of Computer Programming
     [1] The Pragmatic Programmer
     [3] Refactoring: Improving the Design of Existing Code
[3] Refactoring: Improving the Design of Existing Code
     [2] The Art of Computer Programming
     [4] Introduction to Algorithms
[4] Introduction to Algorithms
     [3] Refactoring: Improving the Design of Existing Code
     [5] UML Distilled
[5] UML Distilled
     [4] Introduction to Algorithms

S tím, že se vykonají následující dotazy:

SELECT [book].* , (SELECT [prevbook].[id] FROM [book] [prevbook] WHERE [prevbook].[id] < [book].[id] ORDER BY [id] DESC LIMIT 1) AS [previous] , (SELECT [nextbook].[id] FROM [book] [nextbook] WHERE [nextbook].[id] > [book].[id] ORDER BY [id] LIMIT 1) AS [next] FROM [book]
SELECT [book].* , (SELECT [prevbook].[id] FROM [book] [prevbook] WHERE [prevbook].[id] < [book].[id] ORDER BY [id] DESC LIMIT 1) AS [previous] , (SELECT [nextbook].[id] FROM [book] [nextbook] WHERE [nextbook].[id] > [book].[id] ORDER BY [id] LIMIT 1) AS [next] FROM [book] WHERE [book].[id] IN (1, 2, 3, 4)
SELECT [book].* , (SELECT [prevbook].[id] FROM [book] [prevbook] WHERE [prevbook].[id] < [book].[id] ORDER BY [id] DESC LIMIT 1) AS [previous] , (SELECT [nextbook].[id] FROM [book] [nextbook] WHERE [nextbook].[id] > [book].[id] ORDER BY [id] LIMIT 1) AS [next] FROM [book] WHERE [book].[id] IN (2, 3, 4, 5)

Věřím, že mé myšlenkové pochody jsou z té ukázky dobře patrné.

A teď ještě takové malé zamyšlení… Ty dotazy nejsou úplný skvost a také je nehezké, že to není lazy. ID předchozí a následující knihy se zjišťuje bez ohledu na to, zda bude zapotřebí. Jenomže udělat to úplně lazy asi není principiálně dost dobře možné… Nabízí se možnost ta ID dopředu nezjišťovat, ale pak by je bylo nutné nějak rekonstruovat při traverzování. To by ale asi nebylo vzhledem k „NotORM“ stylu dotazování možné…

Východiskem je samozřejmě udržování těch ID „předvypočtených“ přímo v databázi. Pokud by se výše uvedené řešení ukázalo jako problematické z výkonnostního hlediska, nebál bych se toho. Integritu lze s použitím Lean Mapperu zaručit (i když ony ty dotazy budou rychlé, ke všemu se použijí indexy).

Edit: Samozřejmě by také šlo mít položky $previous a $next až v nějakém potomkovi Book (třeba TraversableBook?) a v případech, kdy se dopředu ví, že toto traverzování nebude zapotřebí, by se mohlo pracovat s entitami Book. Je to ale už trochu překombinované…

Mimochodem netvrdím, že neexistuje nějaké celkově lepší řešení. :)

Editoval Tharos (7. 2. 2014 23:57)

@Ripper: Ahoj, já se s tím moc nepářu a filtry registruji v bootstrap.php… Netvrdím ale, že je to ideální.

Lze je registrovat všude možně: v nějaké samostatné, k tomu určené třídě, v nějakém LeanMapperExtension kompileru… poslední zmíněná varianta by se mi líbila asi nejvíce, ale sám takové rozšíření napsané nemám. :–P

@Tharos

ta druhá varianta je o poznání přívětivější :-) děkuji moc, jdu to vyzkoušet

@Tharos: chtěl jsem se zeptat jak to vypadá se samostatným LM fórem, případně dá se s tím nějak pomoct? Přeci jen dotazy na LM začínají dosti zasahovat do Nette fóra a asi to není úplně žádoucí…

Ahoj,

chtěl bych do selectu formuláře v nette přidat prvky. Jak z pole entit udělám pole $key ⇒ $val existuje na to nějaká metoda nebo je třeba pro iterovat pole entit? děkuji

Michal III napsal(a):

@batko:

Ahoj,

odkážu Tě sem, kde se i o pár příspěvků dál nachází rozřešení.

Jenom upozorňuji, že nyní se protected metoda createCollection nachází ve tříde DefaultEntityFactory, kterou sis nejspíše podědil.

Super dík moc.

Ještě malý dotaz.

Odešlu formulář a mám v něm multiselect který mi vrací pole hodnot. Ale já bych potřeboval, aby vracel pole objektů aby se to mohlo rovnou persistovat.

Mám entitu článek a ta má entity gallery[]. A ty gallery vyberu v multiselectu a odešlu.

Editoval batko (18. 2. 2014 21:50)

Ahoj, omlouvám se za trochu zpožděnou reakci, mám teď trochu méně prostoru…

Protože už to tady nechci moc SPAMovat, chci všem nabídnout support na Skype v.kohout nebo na Jabberu tharos@jabber.cz. Do té doby, než bude mít Lean Mapper své vlastní fórum.

Díky!

Zveřejnil jsem rozšíření LM
Jde o přidání Query objectu, vlastního mapperu zohledňující namespace Entit/Repozitářů v submodulech, repozitář pracující s Query objektem a překládajícím názvy property na sloupce databáze.

Readme s popisem všech fičur přidám večer, nejpozději zítra…

Upozorňuji ale, že nepoužívám nejnovější (nezdokumentované) úpravy LM (používám verzi 2.0.1), takže negarantuju, že to pojede na novějších. Pokud budu vědět, jak to zprovoznit pro aktuální verzi LM, tak udělám druhou větev, kde ty změny zapracuju…

@Tharos: Já bych určitě rád něčím do dokumentace přispěl a doufám, že to není jenom planý slib. Mít k dispozici hlavní témata a nějaké body bude moc fajn → rád plním body, pokud zrovna ten bod není „napsat dokumentaci k LM“ :-).

@Tharos: pokud by existoval nějaký seznam bodů, také rád k dokumentaci přispěji… :-)

@Tharos: Plánuješ do LeanMapperu přidat Extension pro Nette? (dalo by se to tam jako bridge stylem co ma dibi). Zatím používám svůj nedodělaný (pokud bych ho dodělal tak bych klidně poslal PR do LM repa), který umožnuje více připojení a nastavení mapperu a filtrů pomocí configu.
Momentálně zápis configu vypadá takto (zatím bez přidávání filtrů)

Pouze jedno připojení: @connection

leanmapper:
    mapper: App\Mapper
    entityFactory: App\EntityFactory
    connection:
        driver: mysql
        host: localhost
        username: USERNAME
        password: PASSWORD
        database: DATABASE
        lazy: TRUE

Více připojení: @connection.forum, @connection.content

leanmapper:
    mapper: App\Mapper
    # pokud nenastavím mapper nebo entityFactory tak se pouzije defaultní z LM
    connections:
        forum:
            driver: mysql
            host: localhost
            username: USERNAME
            password: PASSWORD
            database: DATABASE
            lazy: TRUE
            autowired: no
            inject: no
            # pokud nastavím mapper nebo entityFactory v určitém připojení, tak se použije místo globálního
            entityFactory: App\EntityFactory

        content:
            driver: mysql
            host: localhost
            username: USERNAME
            password: PASSWORD
            database: DATABASE
            lazy: TRUE

Editoval EIFEL (27. 2. 2014 14:38)

Ad dokumentace) Tak super! Díky moc za podporu. Já se tedy ASAP pokusím připravit infrastrukturu. Mám vcelku pokročilou představu, jak by to celé mohlo fungovat, a vystačili bychom si jenom s Gitem (GitHubem). Mám teď opravdu hodně nabito, ale snad se k tomu přes víkend dostanu… Ty cca tři hoďky bych prostě měl najít.

Ad extenze) Já jsem samozřejmě rád za každou, jaká vznikne. :) Pokud by měla existovat nějaká „oficiální“, je k diskuzi, co by měla řešit. Jednou už jsem tu o tom někde psal. Diskuzi o tom už bych ale nechal na samostatné fórum… Tady by to bylo hezké s 1000. příspěvkem tak nějak opustit. ;)

A zkoušel jsi tohle?

<?php
/**
 * @property int              $id
 * @property \DateTime|string $start
 * @property \DateTime|string $end
 */
?>

Editoval Šaman (4. 3. 2014 19:02)

duke napsal(a):

@Šaman Zkoušel. Způsobí to chybu:
Invalid property definition given: @property \DateTime|string $start in entity …

Nicméně, i kdyby to fungovalo, tak by to ne zcela řešilo můj problém.
PassThru řešení funguje; jen hledám jeho obecnou variantu, abych nemusel psát passThru u všech sloupců typu \Datetime u všech entit.

Musel by si upravit repository a tam kde se kontroluje typ mit vyjimku pro \DateTime aby když je null tak vrátit $date = new \DateTime(‚0000–01–01‘) (i když nechápu proč nevracíš NULL… přijde mě to víc logické než 0000–01–01 datum)

@duke: Vůbec jsem netušil, že Dibi v takové situaci (datum „0000–00–00 00:00:00“) vrací string. Nikdy jsem na to nenarazil…

Tohle je souhra dvou „specialit“. Databáze umožní uložit uvedený datum, který je IMHO nesmyslný, a dibi z toho udělá string. Babo raď, co z toho udělat na úrovni entity…

Od stolu mě nenapadá žádné elegantní řešení aplikovatelné v současné verzi. Popravdě řečeno já bych v tomhle případě měl v databázi datum jako nullable a zbytek se pokusil vyřešit nějakou výchozí hodnotou a třeba příznakem, zda už datum byl nebo nebyl nastaven…

Jak by sis představoval optimální řešení? Co třeba nějaký výchozí passThru podle typu položky?

Editoval Tharos (5. 3. 2014 14:52)

Ahoj, měl bych dotaz ohledně @property-read, potřeboval bych v entitě uchovávat položku created, kterou nechci, aby kdokoli z kódu měnil, ale zároveň tu hodnotu created potřebuji sám před uložením nějak nastavit – jak nejlíp na to? Nastavovat to nějak na začátku persist() metody v repozitáři (jak?), nebo přetížit nějakou metodu v entitě a nastavovat to v ní? Jak něco takového obvykle řešíte? Díky moc.

PS. pokud se to tu někde už řešilo, tak se omlouvám, prohledával jsem celé forum, ale odpověď na toto jsem nikde nenašel.

Vytvořit trigger by taky byla možnost, ale i když to má svou logiku (je to záležitost databáze a ta by se měla o správnost dat postarat), tak se mi vytváření triggeru kvůli nastavení jedné hodnoty příliš nelíbí, navíc tento sloupec mám skoro u všech tabulek, takže řešit to triggery se mi příliš nechce.

Aktuálně jsem to vyřešil přetížením metody getModifiedRowData() v entitě:

public function getModifiedRowData()
{
    $data = parent::getModifiedRowData();
    if ($this->isDetached()) {
        $data['created'] = new \DateTime;
    }
    return $data;
}

Snad v tom není skrytý nějaký zádrhel.