Ještě nějakou chvíli není a nebude, teprve za pár dní si ho bude moct ošahat jiný člověk než já a až nasbírám feedback a ověří se pod reálným projektem výkon a návrh API jako schůdné, pak půjde ven. Určitě se pak objeví na githubu.

1. Naopak můžu říct, že Honza komunikuje i mimo fórum, například po IM či na Posledních sobotách, kde věci jako komponenty do Nette i ORM probírá a zajímají ho i názory druhých. Otevřená diskuse... no ono je to složitější, co člověk to jiný názor, nakonec se z toho vyklube flame kdy každý tvrdohlavě zastává svůj postoj a jen se kecá místo toho aby se programovalo. Díky tomu padl i jeden projekt Nette komunity okolo vytvoření CMS - 15 programátorů jen kecalo a řešily se až takové blbosti jak odsazovat switch a k programování se nakonec ani nedostalo :) 2. S tím souhlasím, je to tak jak píšeš... navíc když už sepíše člověk nějakou úvahu, tak to lidi stejně nečtou (je i dokázáno, že lidi web jen prohlížejí :-)) a pokud ano tak se u první věci, ve které s autorem nesouhlasí zastaví, skočí na komentáře a jdou si zanadávat... 3. Určitě se nedá popřít, že z DibiTable Ormion nevyšel. I já vycházel ve svých modelů právě z API DibiTable, lišila se jen implementace a i já mám v modelech onen šikovný *magic fetch*, který je v DibiTable 4. Vím o pěti: tvé DbDibiOrm, Dorm od Honzy Vlčka (vlki), Ormion od Honzy Marka, nějaký zatím nejspíš neveřejný počin Romana Nováka (Jod) a můj 5. Že se najde člověk, který by nesouhlasil, to je dá se říct jasné :-) vždy se někdo najde. Řek bych, že jsou v podstatě 3 základní a známé návrhové vzory a každý to pojímá jinak: - "Table Data Gateway":http://martinfowler.com/eaaCatalog/tableDataGateway.html (ekvivalent DibiTable): asi nejjednoduchší a díky dibi i v Nette aplikacích i hojně používané - vrácený objekt reprezentující záznam z tabulky obsahuje jen své hodnoty a je velmi jednoduchý a neimplementuje nad sebou žádné operace (viz DibiRow) - "Data Mapper":http://martinfowler.com/eaaCatalog/dataMapper.html: ten už vrací objekty, které mají nějaké schopnosti nad sebou samotnými, např třída reprezentující záznam z tabulky už může dejme tomu disponovat validací, nějaký uživatelský data pre/post-processing dat, definovat nějaké dodatečné gettery, settery apod. Neví ale nic o objektu mapperu, který provádí samotné dotazy na db a naopak mapper nic nepotřebuje vědět o objektu (maximálně jak si z něj vytáhnout data pro uložení) "Active Record":http://martinfowler.com/eaaCatalog/activeRecord.html vnímám jako takovou kombinaci obojího, kde je vše nacpáno do jedné třídy (ikdyž záleží na implementaci), objekt reprezentující záznam se umí uložit, zvalidovat, pomocí finderů naplnit a podobně. Záleží na člověku co upředňostňuje. Mě se zamlouvá oddělení funkčnosti (záznam si neuchovává v sobě nic co nemusí, příkazy vykonává někdo jiný), které zavádí Data Mapper ale zároveň i komfort, který poskytuje Active Record (záznam se umí uložit a zvalidovat). Proto jsem se vydal cestou, kde se snažím tyto způsoby zkombinovat a zárověň oba vzory (v rámci možností) dodrřet a moc nezprznit. Na to aby to šlo ven je ještě brzo, ale ven to půjde ;) Musí nejdřív vykrystalizovat API a ověřit v reálném nasazení. Tento způsob se mi ověřil i při vývoji DataGridu a brzké vydání je myslím i důvod, proč byl pozastaven vývoj DibiTable (David to pustil ven moc brzo a po čase se mu znelíbilo API, ale už to lidi začali používat, takže by se to muselo řešit nekompatibilitama). 7. Mě se například nelíbí zavádění struktur tabulek do kódu, s tím související duplicita a nepříjemnosti při změnách, všemožné šílené definice v polích a podobně. Každé ORM to má navíc řešeno jinak a liší se i v zápise takže je to takové schizofrenické... V dibi je napsána abstrakce nad databázovou reflexí, která má vše co člověk může potřebovat, byla by škoda toho nevyužít a vymýšlet znovu něco co už je vymyšleno. Horší je to s implementací v jednotlivých driverech, ale nic co by se nedalo dopsat (otázka tak na hodinku až dvě i s testy), jsou to jen 4 základní metody. Databázi navíc mohou navrhovat jiní lidi než programátoři konkrétního jazyka, takže tím že si info o tabulce načtu z ní si akorát ušetřím starosti. ad A: V podstatě ano, já sám instanci neukládám, ale zároveň mám možnost, jak v recordu získat mapper, pokud by to bylo třeba, i nechávám uživateli možnost změny mapperu. ad B: Pod result set-em jsem myslel nějakou kolekci záznamů, které ti vrátí metody find() / finder pokud podmínkám / filtrům vyhoví více záznamů. V `dibi::fetchAll` například vrací pole `DibiRow` objektů. Aby aplikace nevyhnila v případě velkého objemu záznamů, tak je třeba aby záznamy byly opravdu pokud možno co nejhloupější a takové věci jako datové typy sloupců, jejich výchozí hodnoty, povinnost/nepovinnost a podobné neobsahovaly, ale uměly je nějak lazy získat. Já tyhle věci například ukládám a načítám z/do keše, když si o ně poprvé řeknu, mám to zastřešeno nějakými objekty o určitém rozhraní, takže když se někomu nebude líbít, že získávám info o tabulce pomocí databázové reflexe, nic nebude bránit podědit a přepsat onu metodu a objektu podstrčit konfiguraci třeba z konfiguráku nebo klidně i z toho pole. Takže jsou tam mám i jisté závislosti na částech Nette, ale nic co se nedá ve finále vyseparovat. Uff myslím, že to bylo vyčerpávající :-)

1. Pokud ti (jak píšeš) nesedí sdružování objektů, zkus se podívat na návrhový vzor Data Mapper. DibiTable využíval/se blížil návrhovému vzoru Table Data Gateway. Pojednává se o nich například v knize *Patterns of Enterprise Application Architecture*. 2. DibiTable parsovat SQL dotaz pro vytvoření tabulky (pokud vím) nikdy neumělo, tahle informace vznikla nejspíš z jednoho příkladu, kde byl v komentáři třídy zakomentován `CREATE TABLE`, aby čtenáři měli nějakou představu o struktuře tabluky. 3. Nejdokonalejší řešení je dle mého reflexe na databázi, sám mám nad dibi napsané ORM, které toho využívá 4. Teď jsou na to v příkladech vhodnější praktiky, naříklad nějaká statická metoda modelu + využití události aplikace (onStartup), nebo si připojení nadefinovat jako službu... možností je spousty, to co používal David bylo spíš pro jednoduchost příkladů. 5. Opět se odkážu na návrhový vzor Table Data Gateway, který Dibi table používá - takovýto přístup totiž neřeší, je třeba si v tom udělat pořádek, ať člověk nevědomky nevyčítá něco, co není podstatou třídy 6. Tady se opět hodí více Data Mapper (mapper bude disponovat metodou save, která bude schopna přijmou jednotlivé záznamy nebo nějakou kolekci záznamů a na základě toho se rozhodne, jak nejefektivněji uložit).

Koukám, že se ORM nad dibi se v poslední době nějak rozrhl pytel, tohle je už asi pátý, který vidím. Nicméně žádný pořád není dokonalý. Pokud máš instanci DibiConnection v každé instanci třídy DbRow, tak už při druhém je to zbytečné, natožpak nějaký result-set o tisíci řádcích. Další bolest skoro všech Orm je duplicita a zanášení definice struktury databázových tabulek někam, kam nepatří (viz. http://github.com/matak/DbDibiOrm/blob/master/libs/Customer/CustomerConfig.php). V komentářích jsou ještě nějaké zapomenuté anotace @return Ormion, tak bacha na to ;) Btw: jsi si opravdu jist, že metoda __toArray() je v objektovém modelu PHP implementována?