Lean Mapper – tenké ORM nad dibi

V prvom rade by som chcel autorovi vzdat velku pochvalu a velke podakovanie! Rozhodol som sa do mojho CMSka implementovat LeanMapper a az na par drobnosti som s nim velmi spokojny! Avsak.. mam par navrhov, ktore sice momentalne riesim dedicnostou – udalosti. LeanMapper momentalne sice disponuje funkciami ako beforeCreate, beforeUpdate… Ja by som navrhol pridat este – beforeDelete / afterDelete.

Priklad pouzitia:
Mam model, ktory sa stara o galerie. Kazda galeria ma svoj vlastny priecinok, kde su fotky. Ked odstranim galeriu, potrebujem aby sa mi odstranil aj jej priecinok – cize tu by bolo vhod pouzit bud beforeDelete alebo afterDelete (vysledok bude taky isty).

Este ma napadlo aj afterPersist, ale jediny, ktory ma napadol by bolo invalidovanie cache…

peter.z napsal(a):

velke podakovanie!

Není zač, jsem moc rád, že knihovna slouží. :)

udalosti. LeanMapper momentalne sice disponuje funkciami ako beforeCreate, beforeUpdate… Ja by som navrhol pridat este – beforeDelete / afterDelete.

Priklad pouzitia:
Mam model, ktory sa stara o galerie. Kazda galeria ma svoj vlastny priecinok, kde su fotky. Ked odstranim galeriu, potrebujem aby sa mi odstranil aj jej priecinok – cize tu by bolo vhod pouzit bud beforeDelete alebo afterDelete (vysledok bude taky isty).

Este ma napadlo aj afterPersist, ale jediny, ktory ma napadol by bolo invalidovanie cache…

Tohle je rozhodně dobrý nápad, ale rád bych skutečně dobře rozmyslel API. Viděl bych to jako feature do verze 1.6.

Tak trochu problém je, že já sám pro něco takového využití nemám, protože já zpravidla s repositáři pracuji v nějaké servisní vrstvě a když je například zapotřebí po odstranění záznamu z databáze něco smazat i na disku, řeším to v rámci jedné metody v té servisní vrstvě.

Mně tenhle styl práce vyhovuje, ale samozřejmě chápu, že kdekdo má model navržený jinak a události by mu usnadnily život…

Co tím ale chci říct: je otázkou, jestli jsem ten pravý pro návrh API téhle funkcionality. :–P

Určitě bych byl rád, aby to bylo maximálně jednoduché. Napadlo mě mít prostě dostupné události a k těm mít možnost registrovat (rozuměj štosovat) callbacky (podobně fungují třeba Nette formuláře).

Současné metody beforeCreate(), beforeUpdate() a beforePersist() mají trochu jiný účel. Ty slouží k úpravě dat bezprostředně před jejich odesláním do databáze (jako například zde). Tyhle metody bych rozhodně zachoval, ale vedle nich bych zavedl tzv. události pro realizaci čehosi, co bych nazval vedlejšími efekty.

Mohlo by to fungovat třeba takhle?

$repository = new Repository($connection, $mapper);
$repository->addEventCallback(Repository::EVENT_BEFORE_UPDATE, function () {
    // do something here
});

S tím, že by pak v základním repositáři mohla existovat i nějaká protected metoda initEventsCallbacks() ve stylu initDefaults(), která by umožnila nastavit nějaké výchozí callbacky u konkrétního (poděděného) repositáře. Callbacky by tak bylo možné nastavit jak pomocí této metody, tak i dynamicky za běhu.

Bylo by to takhle dobře použitelné? Řešilo by to vše potřebné? Jaké události by měly existovat? A jaké parametry by se měly předávat těm callbackům?

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

Dneska mám takový vtipný den… Rozhodl jsem se vyprofilovat Lean Mapper na větších datech. Pořídil jsem si MySQL databázi Employees a pustil se do práce. Po nejrůznějších experimentech jsem zanesl do knihovny několik málo nenápadných optimalizací, které ale dokáží v mnoha případech výrazně zvýšit výkon.

Když už se v Lean Mapperu nenacházela žádná další vyloženě úzká hrdla, napadlo mě ještě alespoň bleskově porovnat, jak si vede ve srovnání s jinými knihovnami. Protože výkonu Lean Mapperu velmi věřím, zaměřil jsem se na srovnání s NotORM a s Nette\Database (s cache i bez ní).

Nechce se mi věřit vlastním očím a už hodiny přemýšlím, jestli náhodou něco nedělám špatně…

Zadání: Vypište z Employees databáze pět set zaměstnanců a pro každého uveďte všechny jeho výplaty (vztah belongs to many) a také všechna oddělení, do kterých patří (vztah has many). Zkrátka získejte z databáze takovýto přehled.

Doba trvání:

Lean Mapper ~ 1.6 s
NotORM ~ 6.2 s
NDB ~ 16.7 s
NDB s cache ~ 25.6 s

Není moc pracné zjistit, v čem je zakopaný pes. Stačí se podívat na následující výstupy z WinCacheGrind seřazené sestupně podle Total Self (pro účely profilování jsem musel snížit limit zaměstnanců na 200, protože záznam z NDB s pěti sty zaměstnanci se mi ani nepodařilo kvůli nedostatku paměti otevřít :–P).

NotORM i Nette\Database trpí tím, že jakmile jsou vystavené většímu množství dat, dokáží je sice získat efektivně z databáze (pomocí IN), ale pak s nimi provádějí příliš mnoho operací. NotORM_Result->quote je voláno 80 410 krát, ActiveRow->accessColumn dokonce 140 011 krát!

Ptám se proč tolikrát? Nevidím do vnitřností těch knihoven a samotného by mě to vcelku zajímalo… Jde o velmi rychlé metody, ale při takovém množství zavolání jde prostě jakýkoliv výkon do kytek. A největší kuriozitou je: chcete zlepšit výkon Nette\Database? Vypněte si cache! :)

Motivován touto zkušeností připravím nějaký ucelenější benchmark, protože mě to celé až vyděsilo. Pokud jsem ještě zvýšil limit zaměstnanců (třeba na 10 000), nůžky se ještě více rozevřely. Je možné, že je Lean Mapper při větším množství dat o řád výkonnější než NotORM?

Mile rád zveřejním kompletní kód benchmarku pro oponenturu. Skoro doufám, že mám v metodice nějakou chybu!

Editoval Tharos (8. 7. 2013 21:50)

Taky mě překvapilo, jak je NDB šíleně pomalé a kolikrát se accessColumn volá. Asi by to chtělo zapracovat na optimalizaci.

@Tharos: Zajímalo by mne jak by ve tvém srovnání obstála Doctrine. ;-)

@Tharos: můžeš do výkonostního testu zahrnout taky samotné dibi? (nebo je to hlavně o ORM?)
Docela by mě zajímala režije samotného LeanMapperu.

@**Tharos**: Zkus tu definici memcache keše nahradit za:

use Doctrine\Common\Cache\FilesystemCache;
$cache = new FilesystemCache(__DIR__ . '/temp');

Při druhém běhu by to mělo být OK (u mě vpodstatě stejný čas jako s memkeší).

Ale samozřejmě souhlasím, že je to celkem vratké srovnání. Nicméně sám jsem byl potěšen výsledkem, kdy se zdá, že Doctrine je rychlejší než NDB (což mě ostatně vlastně ani nepřekvapuje) a dokonce i než NotORM. S přihlédnutím ke komplexnosti daných knihoven Doctrine jasně vede.

@Tharos:
Právě že „strategií“ dotazů jsem si nebyl jistý, proto ten otazník :)
Samotná výkonnost dibi mě momentálně tolik netrápí, resp. už se určitě v minulosti řešila jinde. Proto by asi bylo lepší zaměřit se pouze na režii LeanMapperu a proto tedy dotazy s IN?
(dávám zase s otazníkem, protože se přiznám, že jsem zatím nesledoval dotazy generované LeanMapperem – ještě jsem ho nenasadil v ostré aplikaci)

Úplně nejlepší by bylo udělat repo, kde by byl benchmark všech zmíněných DB layerů.

Mimochodem, v Jakubově srovnání NotORM a dibi vyšlo dibi hůř z triviálního důvodů: delimitovalo (obalovalo do zpětných uvozovek) identifikátory, tj. názvy tabulek a sloupců. NotORM to nedělalo a právě o to bylo rychlejší. Takový fakt pak vrhá trošku jiný pohled na výsledky.

NDB by měla být stejně rychlá jako dibi, nejslabším místem (jak už Tharos zmiňoval) je funkce normalizeRow a ta by se mohla poladit. NDB\Table (nemám rád zaměňování NDB a NDB\Table) dosud žádnou rychlostní optimalizací neprošla, což je vzhledem k vývoji pochopitelné, ale rozhodně ji dostane. Nicméně nejde o vrstvu, která je primárně stavěná na načítání 10.000 záznamů.

Btw, je možné, že mám 40× rychlejší počítač než ty? Dávám to za 0.39 sekundy. (Na PHP 5.4.x, na 5.3.x je to 0.7 sekundy).

$connection = new Nette\Database\Connection('mysql:dbname=employees', 'root', 'xxx');

$dao = new Nette\Database\SelectionFactory(
    $connection,
    new Nette\Database\Reflection\DiscoveredReflection($connection)
);

$time = -microtime(TRUE);

foreach ($dao->table('employees')->limit(500) as $employe) {
    echo "$employe->first_name ($employe->emp_no)\n";
    echo "Salaries:\m";
    foreach ($employe->related('salaries') as $salary) {
        echo $salary->salary, "\n";
    }
    echo "Departments:\n";
    foreach ($employe->related('dept_emp') as $department) {
        echo $department->dept->dept_name, "\n";
    }
}

$time += microtime(TRUE);
echo 'time: ',$time;

Tak to už vypadá lépe :-) Můžeš zkusit změřit ještě Doctrine na svém HW a ideálně to doplnit o paměťové nároky via memory_get_peak_usage()?

To dost pozměněné API mě zajímá, můžeš sdělit, na co jsi zásadního narazil? (Tedy krom Connection::table vs. SelectionFactory::table). Ale připomněl jsi mi, že jsem zapomněl vydat Nette 2.0.11, čas to napravit.

BTW, NDB je v dev verzi 6× rychlejší než v 2.0.x, dobrá práce Hrachu!

Predpokladam, ze je jeste necherry-picknuta nova syntaxe pro backjoin (pac je BC break), ktera ale v Tharosove testovacim scriptu neni vyuzita.

Na mém HW to vypadá takto:

A když navíc srovnám délku kódu potřebnou k vyřešení úkolu, není snad potřeba existenci NDB víc obhajovat.

(Poznámka: rychlost měření ovlivňují faktory, které vůbec nečekáte, třeba nastavení date_default_timezone_set() může zvýšit výkon o 10 %).

David Grudl napsal(a):

Na mém HW to vypadá takto:

Zkoušel jsi to na 5.5 a s OPcache nebo bez? Zrovna opcode keš může u velké vs. malé knihovny znamenat zajímavý rozdíl (zejména paměti).

Ale připomněl jsi mi, že jsem zapomněl vydat Nette 2.0.11, čas to napravit.

Tharos napsal(a):

Tak pokud bys měl chuť, můžeš do srovnání zahrnout i Lean Mapper a NotORM.

Jasně, díky za kód, je to tam :-) Jseš vítěz!

Docela by bylo zajímavé změřit Lean Mapper nad NDB místo dibi (nemyslím teď NDB\Table). Ale nemám moc čas to zkoušet předělávat, byť nemyslím, že by to bylo složité.

Abych trochu změnil téma…

Lean Mapper má od neděle jednu zajímavou novou funkcionalitu: výrazně lepší podporu pro single table inheritance. Věřím, že příklad vydá za tisíc slov.

Nosnou úpravou je přidání druhého parametru do metody getEntityClass v mapperu. Nově tedy mapper může o relevantní entitní třídě rozhonout i na základě konkrétních dat, které má entita zapouzdřit. Užití je velmi široké.

Doposud bylo nutné single table inheritance ošetřovat na úrovni metod v entitě a bohužel často ještě duplicitně v repositáři. Nyní lze vše elegantně řídit z jednoho místa.

Možná jste si všimli, že tím typ v anotaci trochu ztrácí váhu. Je tomu skutečně tak – v položce nadefinované pomocí @property Product $product se ve výsledku může objevit PC, Printer, TV…

Možná vás potěší, že Lean Mapper v tomhle případě dbá na konzistenci a nedovolí, aby se v dané položce objevilo něco jiného, než instance podle type hintu anebo instance nějaké odvozené třídy. Pokud se například do výše uvedené položky pokusím pomocí mapperu dostat instanci entity Customer, která nedědí od Product, Lean Mapper vyhodí následující výmluvnou výjimku:

Inconsistency found: property 'product' is supposed to contain an instance of 'Model\Entity\Product' (due to type hint), but mapper maps it to 'Model\Entity\Customer'. Please fix getEntityClass() method in mapper, property annotation or entities inheritance.

Enjoy

Dal jsem ty včerejší testy do repa https://github.com/dg/db-benchmark, můžeme na to navázat a sadu testů rozšířit. Jo, jak jsem oddělil NotORM do samostatného adresáře, tak hodně klesla paměťová náročnost, tak jsem to v tabulce upravil.

@Tharos:
Zase trochu z jiného soudku – vícejazyčné entity.

Neměl jsem v posledních dnech moc času, takže jsem se zase vrátil k testování v minulosti navrhovaného řešení, tedy entita s translatable prvky a translatable repository, které automaticky pomocí filtru načte entitu z tabulky hlavičky i textů, resp. uloží do těchto tabulek.

Entita:

/**
* @property int $id
* @property Gallery|null $gallery m:hasOne(gallery)
* @property bool $status
* @property string $lang m:translatable
* @property string $title m:translatable
* @property string $text m:translatable
*/
class Content extends TranslatableEntity {
}

TranslatableRepository samo o sobě dokáže s entitou pracovat dobře a dělá to co od něj očekávám. Problém ale nastává u relací, konkrétně u téhle entity

@property Gallery|null $gallery m:hasOne(gallery)

Pokud načtu entitu Content a použiji $content->gallery, LeanMapper načte data přímo z tabulky gallery a na nějaké moje translatable repository se úplně vykašle. Výsledkem je tedy objekt Gallery definovaný jako translatable, ale v $row jsou načtená data jen z tabulky gallery.

Ono je to samozřejmě naprosto logický chování – bohužel jsem si to na začátku neuvědomil a pro mě je naprosto nežádoucí. Má představa je načtení celé konzistentní translatable entity Gallery (tedy s pomocí GalleryRepository, resp. TranslatableRepository).

Nějaký nápad co by se s tím dalo dělat nebo jsem skončil?

Díky.

@Tharos:
Tak to mam opět radost :)

Použití filtru v anotaci jsem úplně přehlédl a samotný filtr jsem pojal trochu jinak. Tvůj (PageFilter) jsem zrušil a vytvořil si metodu v TranslatableRepository, protože se mi nechtělo pro každou entitu definovat vlastní filtr.

public function joinTranslation(DibiFluent $statement, $lang) {
    $statement->leftJoin($this->translationTable)
        ->on('['. $this->translationTable .'.id] = ['. $this->getTable() .'.id]')
        ->where('[lang] = %s', $lang);
}

Volal jsem ho tedy ručně v repository, když bylo třeba.

$this->joinTranslation($statement, $lang);

Při použití m:filter a definování konkrétního filtru pro Gallery entitu se mi načte celá entita správně, jen mi to boří koncept, kde nepotřebuji mít pro každou entitu vlastní filtr, ale generuje se automaticky podle anotace v repository

/**
 * @translationTable(gallery_text)
 */
class GalleryRepository extends TranslatableRepository {

}

Ještě to promyslím.

@Tharos:
Zkusím do té doby taky něco udělat.

Jak zmiňuješ $author->getPages('cs'), tak podobné použití je žádoucí.
Můžu třeba v šabloně potřebovat vypsat vedle sebe názvy v několika jazycích, takže třeba následující kód smysl má.

$author->getPages('cs')->title
$author->getPages('en')->title
$author->getPages('de')->title

V praxi je tomu ale obvykle jinak – jazyk se nastaví jednou a dost. Tedy chtěl bych zkusit vymyslet jak jazyk nastavit jednou (asi v TranslatableRepository) a pak už ho vůbec nepředávat, aby fungovalo i následující:

$author->pages->title

Ještě jsem uvažoval zda by nebylo užitečný taky přiřazování

$author->getPages('cs')->title = 'nazev';
$author->pages->title = 'nazev';

ale někde jsi psal, že Entita neumí persistovat sama sebe, tedy takovouhle úpravu nedokáže uložit a je potřeba pracovat s repository (v tomhle případě s AuthorRepository a PagesRepository).

@Šaman: Je-li hodnot více, je lepší místo enumu použít extra tabulku. Chceš-li vracet přeloženou hodnotu (tj. např. místo m můž), přidej si na to např. extra getter.

Tak už jsem zase zpátky. :) Vezmu to postupně…

@Šaman:

Je i není (k tomu nějaký důvod). Prapůvodně v tom byl jistý záměr – aby šlo explicitně ovlivnit, jestli se zavolá metoda nebo použije magický přístup… Ale s odstupem mi to přijde trochu nešťastné. Zejména proto, že to svádí k tomu mít nadefinovanou nějakou položku kombinovaně pomocí anotace i metody, což je „bad practice“. Pravidla, kterými se Lean Mapper v takovém případě řídí, jsou sice jasně daná (viz ta dokumentace), ale totálně neintuitivní… Říkám si, jestli to z dokumentace časem nevyhodím…

Doporučení zní:

• Položky definujte pomocí anotací, pokud není nutné něco vyloženě extra.
• K položkám přistupujte pomocí magické __get metody ($book->name), dokud položka nemá nadefinovaný filtr, kterému potřebujeme při volání předat nějaké parametry ($book->getTopBooks(5) – vrátí pět nejlépe hodnocených knih).
• Položky definujte buďto pomocí anotace, anebo pomocí metody. Nikoliv pomocí obojího. Od verze 1.5 bude dostupný příznak m:hintOnly, který umožní, že IDE bude při přístupu přes __get korektně napovídat i položky ve skutečnosti nadefinované pomocí metod.

Tobě by měl problém vyřešit právě ten příznak m:hintOnly. :) Než bude vydaná verze 1.5, je nutné tu anotaci odstranit (a tím bohužel přijít o hint v IDE – sorry a budu to samozřejmě řešit).

Pokud tedy zůstaneš u svého návrhu… To, co řešíš, se z mého pohledu podobá překladům a já osobně bych zvážil i nějaké řešení ala jazykové překlady.

Pro úplnost už jen uvedu: to, že lze k položkám nadefinovaným pomocí anotace přistupovat pomocí metody, má ten význam, že jedině tak lze předat parametry případným filtrům ($author->getTopBooks(5)).

@Filip111: Během dovolené mi v hlavě uzrálo jisté řešení a rád bych jej zde nadhodil jako další RFC…

Filtry vznikly jako jednoduchý koncept (který jsem já osobně původně používal pouze pro řazení, limity a taky join v entitě přes více tabulek) a až zde na fóru vykrystalizovalo, na co všechno je lze ještě použít (překlady, closure table atp.).

Přiznávám, že od začátku mám jistý vnitřní problém s jejich „statičností“. Dokážu si využití statických metod zde obhájit – filtry jsou běžně jednoduché utility třídy neudržující žádný stav, použití je velmi jednoduché… ale celé to prostě není moc hezké. A taky je to limitující: pokud by například filtr potřeboval ke svému filtrování nějakou jinou službu, nelze mu ji nijak „hezky“ předat (pomocí auto-wiringu atp.).

Napadlo mě provést v Lean Mapperu následující úpravy, které by sice znamenaly drobné BC breaky, ale za mě by za to jednoznačně stály…

Úplně bych zrušil statickou povahu filtrů.

Lean Mapper by zavedl vlastní LeanMapper\Connection, které by bylo poděděné DibiConnection a obohacovalo by jej o správu filtrů:

$connection = new LeanMapper\Connection(...); // same as DibiConnection initialization

function translate(Fluent $statement, Entity $entity = null, Property $property = null, $lang = null)
{
    ...
}

/*function translate($args) {
    if (func_num_args() === ...) { // variant with polymorphism
        ...
    }
}*/

class LimitFilter
{

    public function limit(Fluent $statement, $limit = null)
    {
        ...
    }

}

$limitFilter = new LimitFilter;

$connection->registerFilter('limit', array($filter, 'limit')); // equals $connection->registerFilter('limit', array($filter, 'limit'), Connection::FILTER_ARGS_BASIC);

$connection->registerFilter('translate', 'translate', Connection::FILTER_ARGS_RICH);

V aplikaci by tím vznikly pojmenované filtry. LeanMapper\Connection by vytvářelo vlastní LeanMapper\Fluent, což by bylo „fluent“ odvozené od DibiFluent a umělo by navíc následující:

$statement->where(...)->applyFilter('translate', 'cs');

$statement->where(...)->applyFilterRichWay('translate', $entity, $property);

$statement->where(...)->applyFilter('limit', 10);

Nyní už jen rozvedu, co znamenají technicky ty Connection::FILTER_ARGS_RICH a applyFilterRichWay a za okamžik se dostanu k tomu, k čemu je to dobré.

Pokud filtr zaregistruji bez příznaku (nebo s výchozím příznakem Connection::FILTER_ARGS_BASIC), entita při načítání souvisejících entit předá filtru při jeho spouštění jako parametr $statement a následně všechny další parametry, které byly použity při přístupu k položce pomocí get metody (například při volání $author->getBooks(2) může pomyslný filtr mít hlavičku public function limit($statement, $count) a obdrží právě statement a hodnotu 2.

Pokud filtr zaregistruji s příznakem Connection::FILTER_ARGS_RICH (což je zapotřebí jen výjimečně), entita filtru předá: statement, mateřskou entitu (tj. tu, která načítá související entity), reflexi položky, přes kterou se přistupuje, a za tím všechny další parametry, které byly použity při přístupu k položce pomocí get metody (viz předchozí odstavec).

Pokud filtr zaregistruji s příznakem Connection::FILTER_ARGS_RICH, mohu jej volat pomocí applyFilter i applyFilterRichWay (entita jej ale v takovém případě vždy volá pomocí applyFilterRichWay). Pokud jej zaregistruji bez tohoto příznaku (nebo použiji výchozí příznak Connection::FILTER_ARGS_BASIC), mohu jej volat pouze pomocí applyFilter.

Tohle celé se dá velmi výhodně využít třeba v tom překladovém filtru: při volání z entit (pomocí applyFilterRichWay) lze jazyk požadovaného překladu získat z mateřské entity, při ručním volání z repositáře (pomocí applyFilter) se jazyk požadovaného překladu uvede explicitně.

Význam

• Úplně se zruší statická volání a odstraní se související nedostatky.
• Filtry se dostanou do DBAL vrstvy, kde jim to bude absolutně nejvíce slušet (vždyť ony jen modifikují fluent dotaz).
• Významně se zvýší možnosti filtrů. Například půjde napsat úplně triviální překladací filtr o pár řádcích, který umožní následující:

$book = $bookRepository->find(5, 'cs');

echo $book->author->name; // vypíše český název autora

echo $book->getAuthor('en')->name; // vypíše anglický název autora, jazyk překladu je explicitně uveden

Takovýto filtr bude možné zrecyklovat úplně všude. Na tohle bych připravil nějakou komplexní ukázku ke stažení.

• Díky pojmenování se zkrátí příznaky m:filter a zpřehlední anotace (m:filter(limit) namísto například m:filter(LimitFilter::limit) ještě spolu s use).
• Jako filtr půjde zaregistrovat cokoliv, co pojme call_user_func jako $callback, anebo instance třídy Closure. Opět významné rozšíření možností.
• Usnadní se použití filtrů v repositářích ($connection->select('*')->from('...')->applyFilter(...)).

Zpětné nekompatibility

• Pro ty, kteří filtry nepoužívají, půjde o triviální úpravu. Pouze v config.neon nahradí DibiConnection za LeanMapper\Connection.
• Ti, kteří filtry používají, je budou muset eventuálně převést na tenhle nový systém. Což by ale IMHO také nemělo být až tak náročné…

Jestli to je z mého popisu absolutně nepochopitelné, rovnou to v nějaké veřejné feature větvi naimplementuji a vysvětlím lépe na ukázkách. :)

Editoval Tharos (14. 7. 2013 23:34)

Ad Filtry:
Co místo $author->getBooks(3) použít syntax $author->getBooksFluent()->limitFilter(3)->onlyPublishedFilter()->fetchAll().

Snad by šlo vypustit i to fetchAll() implementací ArrayIterator.

Filtry by byly umístěny v samostatné třídě, která by přijímala v konstruktoru DibiFluent. Třída by byla „na jedno použití“ a její název by se získával z příznaku u anotace.

Ad zbytečný dotaz

Na tohle před pár dny narazil i besanek.

Tohle je rozhodně good point a v každém případě kód upravím tak, aby Lean Mapper takovéto bezvýznamné dotazy vůbec nekladl.

Editoval Tharos (15. 7. 2013 14:15)