update 29.1.2010 je zřejmé, že viditelnost a zapouzdření je nutné rozdělit do bodů 7 a 8, chyba díky za upozornění

Máte pravdu, bod 6. je poněkud zmateně napsaný, kombinuje překrytí a přetížení (celý odstavec kombinuje přetížení a překrytí), nicméně v PHP něco jako přetížení dost dobře udělat nejde. Tedy 29.1.2010 update bodu 6. který pojednává pouze o překrytí, přetížení je o jiných jazycích než je PHP. Bohužel v době psaní článku je to celkem rozšířený nešvar (pro články o PHP) a tak najdete podobných článků více. Co se týče atributů vs. vlastnosti zkuste rozvést jaký je v tom rozdíl.

DB to právě neřeší, kdyby vyskakovala chyba bude určitě mít svoje číslo, záleží na sql_mode jestli máme možnost měnit, jinak mysql striktně tyto chyby nevyhazuje

1. v zahraničí je to neuvěřitelně rozšířené, na webexpu jsem potkal jednoho fina žijícího v Praze, co se zabývá tvorbou těchto systémů, především pro finský trh 2. i poker proti počítači musí být kontrolovaný, stejně jako automaty v restauracích, a měli by být pověřeny ministerstvem financí, shledávám tady stejnou potřebu vzhledem k tomu, že si mohou dovolit reklamu na Nově, asi na tom nebudou špatně, a asi by zvládli i nějakou odměnu některému z politiků přihrát (takže tento business si myslím, že bude vzkvétat, jako každý hazard)

já nesouhlasím, bojuji hodně s tím, abych tento princip dodržoval a čím víc se nutím tím méně mám stresu každá funkčnost určitým způsobem je pro projekt svazující, klade určitá omezení, kdyby už ne žádné tak minimálně nutí programátora přemýšlet jestli nějakým dalším krokem nenaruší něco jiného pracuji na vlastním systému, který je vyvíjen po dobu tří let, neuvěřitelný problém jsou funkce, které využívá např. jen jeden zákazník a zvykl si na ně, vznikli bonusem, jako vedlejší efekt něčeho, bylo velice snadné je tam dodělat, proč ne jenomže vývoj projektu si vyžádal nefunkčnost této funkce, která pro celkový koncept vůbec není důležitá, stojíme před otázkou, že buď musíme zajistit zpětnou kompatibilitu projektu pro chod této funkce nebo musíme tuto funkci opravit, až jich budete takových mít 30 už bude každá změna problém pochopitelně zákazník si za své peníze nenechá nic vzít! už mu nevysvětlíte, že ta funkce není žádoucí! takže z původního bonusu se stává do budoucna sleva uplatňována zákazníkovi za to, že mu bereme něco co jsme udělali z dobré vůle (nebo z blbosti) **YAGNI**

1. věřím, že by to klaplo, už jsem o tom přemýšlel, ale styl businessu mi nějak jde proti srsti (český člověk je správná cílová skupina) 2. naplňuje to formu hazardu, mělo by to být kontrolované stejně jako každá internetová sázkovka, nebo jste nikdy nehrál poker přes net? a věřil jste, že můžete vyhrát? že Vám počítač nekouká do karet?

snad bych jen dodal, procento lidí, kteří sedí na zadku a přemýšlí jak zbohatnou a co, že je ta vlna, je v současné době čím dál vyšší, až snad alarmující, protože kdo za chvíli bude pracovat :) řekl bych, že pár lidí chce naskočit do rozjetého vlaku, ale tady asi záleží na rychlosti, je to podobné jako, když začal boom internetových obchodů, kdo nasedli první sedí v kupé, zbytek se tlačí v posledním vagonu a umírá na nedostatek kyslíku

já sem přesvědčený, že výdělečné jsou! vždyť co lidí hraje automaty spíše bych se věnoval otázce, je to hazard, a neměl by být regulovaný? je to letadlo které není ani nijak kontrolovatelné a proto mne zajímá jestli nějaký ten provozovatel sem tam do hry nepustí nějakého virtuálního černého pasažéra je to podobné jako internetové kasino, taky tam můžete hrát výherní automat a počítač točí třešničkama, a věříte mu, že vám tam vždycky tu náhodnou otočku šoupne? že nepodvádí?

1. Model=řádek tabulky to je jasné, tam není co vymýšlet, ať už bude umět cokoli nebo odkazovat na cokoli co to dělá a vrací přes tento model výsledek (to máme tedy náš Customer, Product, User, Order, Invoice) 2. akorát dál mi není jasná ta podobnost mezi třídou co tahá věci z tabulky a repository, přijde mi, že celkem úspěšně tohle můžeme spojit, nebo považujete Repository za v podstatě db layer? je o tom někde nějaký rozumný a čitelný výtah? nějaký tip?

A není Repository to co říkám? CustomerTable, ProductTable? To je přece vzor Repository ne? Ono ale podle mne i model řádku v tabulce, tedy Product1 (name=šroubovák), nebo Product2 (name=vrtačka), by měl snad umět pracovat s databází ne? Co třeba potřeba 1. ukaž produkty které si někdo zakoupil společně tak asi zavolám Product1->getProductsWhoBuyAlso() samozřejmě bych to mohl předat nějaké Repository (ProductRepository extends Repository) a říci ProductRepository::getProductsWhoBuyAlsoWith(Product1->id) ale není to krkolomné? no možná je to v pořádku, pak tedy model je jen hloupá cache, instance databázového řádku a všechny akce nad ním vykonávám prostřednictvím nějaké černé krabičky případně můžeme implementovat metodu Product1->getProductsWhoBuyAlso() { return ProductRepository::getProductsWhoBuyAlsoWith(this->id) }

Myslím, že tohle je otázka celého programování, ani tak ne ORM. Tabulek právě více mít nemohu, pokud přistoupím k pravidlu, že co tabulka to model. "To možné teoreticky je, ale pak k podtabulce přistupuješ poněkud jinak než tabulce. Kompromisem by bylo to implementovat instančně a udělat statickou obálku." Já chápu dělení ORM na **abstraktní model řádku** a **abstraktní model tabulky** (který chápu spíše jako knihovnu funkcí, knihovnu chování, bez závislosti na okolí / vlastním stavu). Tedy podle mne u Row by měla samozřejmě existovat instance (zajímá mne stav, vlastnosti atd.), u Table snad ani moc důvod k instanci nevidím, resp. proč ne, ale chápu to spíš jako knihovnu která pracuje konrétně s databází, manipuluje s jednotlivými Row objekty, ale sama si nic pamatovat nemusí

jestli tomu správně rozumím, kde získáš $userId tuším že to bude vlastnost presenteru, nebo si ho získal o pár řádků výše z funkce která ho vrátila tedy, spíš auctions = $auctions->getSubtableFo­rOwner($this->user->userId); každopádně nevidím problém v použití $this->auctions = Auctions::getSubtableFo­rOwner($this->user->userId); případně snad může být $this->user->getSubtableFo­rOwner(); ?> tady je snad jasné že to patří userovi, a snad i vidím chybu v trvání na Dependency Injection protože tohle je proti logice opravdu ale přesuňme debatu sem "http://www.webfaq.cz/clanek/DbDibiOrm-DibiConnection-staticky-instancne-pristupovat-primo-k-dibi-factory":http://www.webfaq.cz/clanek/DbDibiOrm-DibiConnection-staticky-instancne-pristupovat-primo-k-dibi-factory vždyť přece staticky se snažím metodu volat jen v případě, kdy právě nemá co dělat se svým okolím, kdy nechci aby byl výstup nebo funkce ovlivněna jejím stav, což podle mne Customers::find nebo Customers::findByName je! mě přece nezajímá jaký je stav objektu? a nechci aby to do toho vztahu nějak vstupovalo, chci vrátit kolekci zákazníků, kteří odpovídají nějakému jménu, proč do toho plést v jakém stavu je Customers / což více méně spíše chápu jako knihovnu funkcí než, aby zaznamenávala nějaký stav

Dělám to tak a dlouho, ale příjde mi to jako neustálý boj. Myslím, že tahle debata patří spíše do tohoto článku. "http://www.webfaq.cz/clanek/DbDibiOrm-DibiConnection-staticky-instancne-pristupovat-primo-k-dibi-factory":http://www.webfaq.cz/clanek/DbDibiOrm-DibiConnection-staticky-instancne-pristupovat-primo-k-dibi-factory

1. prosím určitě to neber jako kritiku, to jakým způsobem bude tahle funkce napsána je dost zásadní, proto jestli má smysl funkce typu **static function find()**, protože pokud je nutné přistupovat k db instančně tak tyhle funkce nemají smysl ve statickém kontextu 2. no to je zhruba to co píšu v článku, tedy mám nějakou abstraktní třídu Customer? a tu podědím do Db1Customer a Db2Customer a každý znich bude pracovat s jiným connection? je to tak, to je jediná možnost využití? Chtěl sem vědět jen jestli to lze nějak reálně použít a jestli tahle funkce má význam protože, jak jsem psal, Customer může někde uvnitř spolupracovat s Productem a ten už zase neví se kterým connection pracovat? tedy existuje příklad využítí takového Dependency Injection? můj názor je, že v případě, že je to konstruováno tak, aby šlo využít DI, tak si odpálím větev pod nohama, aniž bych věděl jestli mám kam skočit

Chápu, že Dependency Injection má dobré myšlenky, ale dá se to v tomto příkladě nějak v budoucnu použít? Tedy říkáš, že statické metody ne, že Customer::find(1) není správně, protože chceme umožnit využívat instanční metody a vlastnosti instance, tedy tato metoda může v nějakém případě mít potřebu přistupovat k něčemu co je instanční a zaměnitelné, krom přístupu k databázi, tedy getDbConnection, což by mne prakticky také zajímalo jak je realizovatelné? save(); $c2=new Customer(); chceš říct, že tady je správné provést něco jako $c2->setDbConnection(dibi::getConnection('db2')); $c2->save(); mě totiž děsí, že pod nohama objektu Customer odpálím připojení k databázi se kterým třeba počítá kdy člověk pracuje v rámci jednoho objektu, jednoho modelu s více databázemi zároveň? napadá mne jedině nějaká forma synchronizace (musí se tedy jednat o naprosto totožné databáze, co když před metodou save ověřujeme jestli má zákazník nějaké produkty objednané a pokud ano zapíšeme i rezervace s jeho registrací? pak tedy voláme objekt Product, který nepočítá s tím, že Customer je už někde jinde, že zákazníka ukládá jinam a produkty by měl ověřovat také v databázi jiného systému? no nevím)

a já měl pocit, že to je jeden z důvodů proč lidi toli požadují late static binding, protože ono i bez toho se dá obejít

Doufám, že se někdo přidá do diskuse k tvému názoru, protože si nejsem jist části: "Jinak použití instancí může mít výhodu použití omezené tabulky – například mám tabulku aukcí. Typickým příkladem omezené tabulky je zde fixace sloupce s vlastníkem tabulky, takže výběr bude filtrován a při vkládání to bude automaticky doplněno. Při update taky není potřeba myslet na přidání další podmínky. Dělat to bez instancí by byl teprve hnus." prosím příklad, nebo bližší vysvětlení ad. názor: už pár let používám to co ty vyzdvihuješ a opravdu mi vadilo pokud sem chtěl například vytvořit form s několika selecty a nemohl jsem použít $form->addSelect("IDexpedition", ExpeditionTable::fetchPairs()); $form->addSelect("IDguaranty", GuarantyTable::fetchPairs()); atd. příjemnější mi bylo i $form->addSelect("IDguaranty", Guaranty::table()->fetchPairs()); než $guarantyTable=new GuarantyTable(); $form->addSelect("IDguaranty", $guarantyTable->fetchPairs()); dále proběhli nějaké další funkce a opět potřebovali vrátit něco od tabulky guaranty a opět sem musel vytvářet novou instanci, takže během jedné funkce jsem třeba 3x musel vytvořit instanci tabulky, jen proto, abych vypsal nějaké páry ale to jen názor, protože funkce na 30-40řádků se stávali hodně nepřehlednými, nicméně stále je to přístup, který upřednostňuje X orm frameworků, řekněme si tedy proč je to špatné nebo je to jen otázka názoru

1. ? která věta konkrétně? přijde mi slovo databáze všude v kontextu použitelné a pochopitelné? 2. opět, která část konkrétně? name="František"; CustomerTable::insert($customer); ?> navrhuješ snad name="František"; $customerTable=new CustomerTable(); $customerTable->insert($customer); ?> ? jendak mi to přijde o řádek navíc a jednak mi přijde, že instance se vytváří úplně zbytečně, pokud to využiji v jedné metodě tak dobrá, ale to mám složitější kód, tak budu pokaždé vytvářet instanci? má to výhodu?

problém s instancí bude, že stěží lze použít např. ve statické metodě Customer::find(1) jak si tady šáhnu na instanci (resp. každá statická metoda co vrací sadu objektů si musí nejprve jeden vytvořit, aby získala připojení k databázi)? to mne nutí ke statické vlastnosti

přihodil bych k tomu jak to řeší jednotlivé existující ORM v PHP, případně jiné, ale k těm už se nedostanu

OK, navrhuji, že udělám serii článků, každý bude řešit jednu otázku, v každém pak udělám nějaký závěr, např. 1. Jak přistupovat k dblayer vrstvě? Vyhovuje Vám staticky, tzn. v každé funkci dibi::query nebo chcete mít možnost nastavit konkrétnímu objektu instanci dblayer vrstvy se kterou má pracovat? Asi ten dblayer omezme jen na dibi. - myslím, že by měla být možnost nastavit objektu různé vrstvy, mě se to hodí v případě, kdy třeba synchronizuji dvě databáze, každá vrstvá má svou connection, je to nepříjemné, že každému objektu musím nastavit se kterou vrstvou má pracovat, ale jak jinak? Navíc snad mohu předávat jen referenci, takže nedojde k duplikacím. 2. Jak udržovat informace o databázovém objektu? Všechnu direktivu zapsat do externího objektu (config), ten generovat přímo z databáze nebo ručně ji vytvořit, dělá to tak např. Doctrine. Nebo kešovat nějaká data v externím souboru a objekt config si je nacte a zparsuje až bude potřebovat, výhoda je, že se snadno dá externí soubor aktualizovat a generovat z databáze pouhým smazáním cache. co říkáš pokračovat tímto stylem a každou otázku řešit v článku, protože jinak to budeme řešit jen my dva a tato diskuse se hrozně nafoukne

1. ano, ale komunikuje jen v rámci nettistů, poslední sobota, forum nette, na internetu se přece pohybují i jiní lidé co o tom mají co říct a nette ani neznají ne? (pár sem jich viděl) 2. cíl: v jednom příspěvku si řešil XY věcí a to vidím jako problém, kdo to čte? vyseparoval bych z toho jen jednotlivé věci a zaměřil se na ně, až dojdem k uspokojivému výsledku, nebo alespoň řadě názorů, vrhl bych se na další, ale možná tudy cesta taky nevede 5. jak se zdá asi by se hodil článek o ORM, o data mapper a table gateway atd., už se mi jeden nabídl, že by ho napsal...tak snad se rozhoupe 7. hm zbyde ti tedy holý objekt co nic neumí a nic o sobě neví ... no tohle by asi chtělo více prostoru na takové téma ad.B: vždyt přece config je statický! můžeš mít záznamů tisíc a tahle informace se přece duplikovat nebude, co se týče té aktualizace a změny těch konfiguračních direktiv, ano máš pravdu, ale není i ke každému objektu načítání configu z cache také zbytečně zatěžující? třeba už jen jak získat tabulku objektu pro vytvoření nějakého sql? Já to třeba dělám takhle Customer::config()->getTable(), a to by znamenalo, že v téhle chvíli to naincluduje nějakou keš s direktivou mysql tabulky a z toho vrátí název table no... návrh ... co na každé takové téma udělat článek ... pod tím rozběhnout diskusi ... až bude více názorů ... udělat závěr ... zapsat do článku a jít dál ... to byl původní záměr ... ono asi nikdy nenajdeme průnik mezi názory všech ... ale až někomu bude vadit takové a takové chování mohl by si najít proč tomu tak je a co přináší jiný přístup ... případně si může vybrat jiné orm ... nebo si ho upravit ... to není přece o novém a novém vynalézání kola ...

Stručně, jasně: Pokud tady napíšu pojďte se podívat na Ormion (pokud vím jediný publikovaný ORM/Data Gateway nad dibi) tak se nic dít nebude a nikdo se na ten kód ani nepodívá. Prosím přihoď své nápady a to co se ti nelíbí. Zkusme kód po kouskách, to že nikdo nebude pročítat celou knihovnu je už vyzkoušené. Slibuji, že pak vše sepíšu, udělám o tom článek a vše pošlu Honzovi, pokud se mu nápady líbit nebudou a nebude to chtít v Ormionu změnit, udělám vlastní implementaci. Pokud se ti chce, budu vděčný, když mi vady na gramatice budeš posílat na email, slibuji, že je opravím 24 do hodin.

no doba pokročila, pokud budeš chtít koukni se na další části (tohle jsem psal po jednodenní známosti s dibi i nette), jde mi hlavně o vyvolání diskuse, stále mne připadá, že je tady obrovské množství programátorů, včetně mne, kteří neumí tyhle témata rozumně uchopit (tedy co se týče PHP, ale proč teda většina dělá v PHP - to je jiná pohádka) je někde to tvé ORM vidět?

díky za názor, konečně něco konstruktivního, 1. Ormion, rád bych ho podpořil, ale nevím o tom, že by Honza nějak komunikoval navenek, pokud vím tak pouze s Nette komunitou na Nette foru, což je podle mne škoda. Navíc neexistuje otevřená diskuse jestli se nemílím. 2. Podle mne, ale napsat Ormion je dibiorm a pojďme se podívat na kód, tak nikdo právě nebude komunikovat a to je ten problém, protože většina programátorů dokáže zkousnout jen utržkovité informace na blogu a proto řeším jednotlivé problémy. Jeslti z toho bude doporučení a nebo vlastní implementace Ormionu už pro mne není důležité. 3. Tomu, že se inspiruji v Ormionu se netajím, a psal jsem to. Dokonce původně jsem názvy některých proměnných přejmenoval tak, aby byly stejné jako v Ormionu. Zavedl jsem funkce, které jsem do té doby nepoužil, nicméně Ormion je naopak pokračování (pokud se nemýlím) Davidova DibiTableX. 4. Existují ještě nějaké další pokusy? Sem s nimi, nevím o tom. 5. DibiConnection je něco co jsem neřešil a popravdě ani k životu nijak řešit v každé instanci nepotřebuji, to je podle mne nejmenší bolest, nicméně ona se opravdu nevytváří znovu, ale stále existuje jen jedna, uložená v Db. Mě však opravdu vyhovuje i statické volání, ale někteří by s tebou nesouhlasili a chtějí mít v každé instanci dibiconnection. 6. __toArray? je to metoda která se mi hodí, dobře vylepším to, když ji nazvu asArray()? v php se pri (array)$object opravdu nezavolá magická metoda a ani nikdy volat nebude! sory za zmatení nepřítele 7. docela fajn by bylo, kdyby každý hodil nějakou tu špínu na různá ORM, z čehož se také dá vyjít, o to mi v podstatě jde. K věci: A. instance dibiconnection, tvrdíš, že nic takového není potřeba a dblayer vrstva se má volat v každé funkci staticky a objektu nic není potom s jakou instancí dblayeru pracuje? B. result-set o tisící řádcích? tak teď asi nerozumím? můžeš rozvést? C. kam to tedy patří? Jak to myslíš že to sem nepatří? Na tom přece každé ORM v podstatě stojí? To je to co udržuje návrh konzistentní ne? P.S.: co používáš ty? já ORM v podstatě nikdy nepotřeboval a přitom už před mnoha lety jsem si něco podobného vytvořil, původně mne štvalo neustále vytváření administrovatelných číselníků, takže časem jsem si vytvořil utilitu, která vygenerovala třídy a mysql apod. které měli na práci jen administrační prostředí a práci s daty jako (id, discount, amount), (id, phe, price) apod. později z toho vznikli třídy pro práci s rozsáhlejšími tabulkami a začali se nabalovat různé funkce, je to hrozný paskvil ale umělo to hodně a teď bych rád to předělal do něčeho systémového

1. neřekl bych, že ORM od Honzy Marka je již vytvořené a ani nevím jeslti ho někdo používá, nicméně i na něj se v článcích odkazuje 2. nemusí úplně každému vyhovovat, snad by i pomohlo někomu pochopit jak ten mechanismus funguje a proč 3. ono je dost těžké do toho zapojit více lidí pokud se vystaví hotová knihovna, 4. tady jde spíš o konkrétní problémy nebo vědět jak se s čím vypořádat, nicméně pokud nechcete objevovat ameriku, pak je tady už delší dobu Doctrine 5. je to spíš o pohledu na věc a na konrétní časti skládačky, proč vymýšlet Nette, Kohanu, CakePHP a další když je tady Zend? P.S.: Nejde mi ani tak o to jeslti výsledkem bude Ormion nebo něco jiného, ale jde mi o vyvolání diskuse, např. mě nevyhovuje, že update vždy vyvolá select do dtb. v mnoha případech je to dost nepoužitelné (s položením téhle otázky ale žádná diskuse nevznikne, a souvisí s tím nakládání s defaultními hodnotami, povinnými hodnotami atd.) P.S.S: Co je neživotné? Možná víc pohledů na věc nikdy neuškodí, jako třeba na slovo neživotné? Můžeš prosím použít v jiné větě? Nějak pořád nevím co přesně to znamená

přidal jsem ukázku na git, článek byl updatován a jsou tam odkazy na zdrojáky co se týče defaultních hodnot budou nestěžejnější metody getValue($name); } public function __set($name, $value) { $this->setValue($name, $value); } public function __isset($name) { if (isset($this->data[$name])) return true; if (isset($this->$name)) return true; return false; } public function __unset($name) { if (isset($this->data[$name])) { unset($this->data[$name]); unset($this->modified[$name]); } else unset($this->$name); } public function setValue($name, $value) { $columns=self::config()->getColumns(); if (isset($columns[$name])) { // vlastnost se uklada do db if (!is_null($value)) { // typova kontrola $type=$s[$string]['type']; if ($type=="%i") $value=(int)$value; elseif ($type=="%f") $value=(float)$value; elseif ($type=="%s" || $type=="%t") $mixed=(string)$value; else throw new DbUndefinedDataTypeException(); } $this->data[$name]=$value; $this->modified[$name]=1; // byla hodnota zmenena? phpactiverecord to oznacuje jako dirty } else { // nejedná se o vlastnost ukladanou do db $this->$name=$value; } } public function & getValue($name) { if (array_key_exists($name, $this->data)) { return $this->data[$name]; } elseif (array_key_exists($name, $this->defaults)) { return $this->defaults[$name]; } else { return $this->$name; } } ?> 1. se domnívám, že chceme zajistit při každém přístupu k vlastnosti objektu volání metody __get a __set 2. metoda __set vždy provádí typovou kontrolu, je to vhodné? 3. je na zvážení jak by se měli chovat hodnoty isset a unset, předpokládám, že defaultní hodnota neznamená že isset bude vracet true, 4. unset předpokládám, že zruší i informaci o tom, že záznam byl někdy modifikován? nějaký další názor na kód?

k věci, ať z toho zase není bezvýznamný flame, neodpověděl si na otázku

citace z článku: "Vytvářet novou instanci new Customer by mohlo být matoucí, co takhle tedy, jak navrhuje Jakub (getByPrimary), to ale také trochu zavání tím, že se to načítá z databáze (programátor by to tak mohl chápat?) a mohlo by to být matoucí." řekněme tedy jiná metoda než konstruktor, tedy new Customer, máš nápad??

zkusím na to udělat příklad snad to bude jasnější

proč by to nešlo, já právě nechci pokaždé načítat záznam, představte si že děláte tohle for($i=0;$i<=40000;$i++) { $p=Product::getByPrimary($i); $p->salesPrice= "slozity vypocet zalozeny na nekolika funkcich a okolnostech, ktere nedovoluji volat hromadne zpracovani, nebo je hromadne zpracovani z mnoha duvodu problematicke, nebo dokonce chci vratit pouze dotaz, ktery volam pozdeji hromadne"; $p->save(); alternativně $update[]=$p->getUpdateSql(); } alternativně $sql->multi_query(implode(";", $update)); protože multi_query je tisíckrát rychlejší a z několika minut zpracování dělá několik sekund! ale to už je jiný článek a opravdu je to tak, věřte tomu prosím, je to tak!

to si opět nerozumíme, 1. právě proto, aby si orm pamatovalo co se změnilo, je nutné využívat magické metody a proto nemůže být nikdy nastavena vlastnost/hodnota právě v takto $this->name, tedy public $name;, ale právě v nějakém jiném poli _data[$name] to už sem psal 2. problém je právě v defaultních hodnotách, následující postup 2a. new Customer - v této chvíli mi to nastaví defaultní hodnoty, tedy $this->payerOfVat=0; tedy ORM si myslí, že payerOfVat byl nastaven, což není úplně pravda protože ve chvíli, kdy provedu update 1. $c=Customer::getByPrimary(1); 2. $c->password="Franta"; 3. $c->save(); mi to změní i hodnotu payerOfVat což jsem vůbec změnit nechtěl, já chtěl změnit jen jeho heslo! samozřejmě je možnost, že metoda getByPrimary, by defaultní hodnoty nenastavovala, ale opět nevím jestli je to OK

tak já se obávám, že __get se bude volat po každé, protože data budou asi uložena jinde než v $this->name, většina ORM, alespoň napsaných v PHP je má uloženy v nějakém poli, tedy typicky $this->_data['name'], hlavně proto, aby poznali při přístupu k hodnotě, že se jedná o hodnotu uloženou v mysql "Jinak jako nástin dobrý, ale doufám, že v této podobě to nikdo nebude používat." co je na podobě špatné?

no asi rozumím jak to myslíš jen mi něco uniká, že nevidíš ten problém (třeba tam není), ale já když provádím save() tak přece vždycky budu k těm hodnotám přistupovat!!! a to je to co nechci! já chci změnit cenu výrobku, aniž bych načítal ten řádek z databáze! Chci udělat tohle 1. $c=Customer::getByPrimary(1); 2. $c->name="František Omáčka"; 3. $c->save(); aniž bych provedl jakýkoli SELECT do databáze

diskuse se už moc rozšiřuje a tak ji přesunu k tomuto článku http://www.webfaq.cz/clanek/ORM-dibi-MySQL-defaultni-hodnoty-pokracovani-clanku

Ujasněme si to: 1. bavíme se stále o DEFAULT, měl by být nastaven už při vytváření nového objektu? a. David říká, že ano b. Jakub říká, že ...

tak to je jiná to jsem nevěděl, máte s tím někdo zkušenost, nicméně je to až tak rozhodující, pro to co by měl jednoduchý ORM umět?

OK díky, za názor, jestli jsem to dobře pochopil odporujete si s Davidem v tomto (ten naopak lazy loading co se týče default považuje za nevhodný, mimochodem dosud to tak řeším, ale právě je to opravdu zmatečné, v mnoha případech bych logicky očekával to a potřeboval opak a kdykoli se ke kódu vracím po delší době, tak musím přemýšlet jak to autor myslel - není to intuitivní)

o sql mode píši v článku také, ale podle mne jsou mizivé šance pro 99% lidí tohle nějak ovlivnit, stejně tak ani když mám vlastní server bych si nedovolil změnit sql mode kvůli 10projektům, protože dalších 90 by mohlo přestat fungovat! nebo se mílím, že taková změna, pokud nejde o stavění serveru přímo na míru dané aplikace je nemožná?

takže navrhuješ při každém updatu objekt nejprve načíst z databáze? to se mi moc nelíbí, hlavně třeba pro hromadné updaty apod. nebo navrhuješ oddělit nastavení defaultních hodnot od konstruktoru? i getById() přece musí objekt vytvořit, pokud teda navrhuješ tohle pak by to znamenalo, že budeš nový objekt vytvářet nějak takto $c=new Customer(); $c->setDefaults(); $c->name="test"; $c->save(); ? nebo jsme se nepochopili?

S těmi defaultními hodnotami je jiný problém, pokud by to bylo opravdu tak, že při vytváření instance nastavím hodnoty na default, pak bude problém při vykonání pouhého updatu. Mám formulář, který např. pouze nastavuje, jestli má zákazník přijímat newsletter, nebo nastavuje jen heslo, tedy chci upravit jen hodnotu password. V takovém případě by nebylo možné udělat. $c=new Customer(); $c->ID=5; $c->password="heslo"; $c->save(); protože by to updatovalo na default hodnoty! v opačném případě bych musel vždy načít obsah objektu z databáze před jeho uložením což je dost značný problém pokud např. z nějakého xml upravuji 40000 řádků stylem, že chci upravit jen cenu, tedy potřebuji $p=new Product(); $p->ID=56; $p->salesPrice=1024; $p->save();

to asi nebude tak jednoduché, já sem s tím zatím spokojen, používám to na řadě projektů, s vysokou návštěvností a složitými dotazy na celkem rozsáhlých tabulkách a funguje to bez problémů, používám to ke stránkování, výhodou je, že mohu vzít jakkoli složitý dotaz a tím že ho strčím do stránkovací factory tak ho mám nastránkovaný, každopádně tohle bude asi jiná pohádka

2. MANDATORY ------------ Tedy navrhuješ, že ORM by mělo kontrolovat a vyhazovat vyjímku v případě, že vlastnost objektu je mandatory? a) Ovšem jak MANDATORY chápat, někdy je nesmyslné, aby prošla i prázdná hodnota. A je to dle mého už omezení databáze, ale to ostatně je i délka řetězce apod. b) Kombinace DEFAULT a MANDATORY je tedy také nesmyslná ne? Pokud se tedy DEFAULT vytvoří už při vytovření instance, tak abych mohl uplatnit omezení nebo ho vůbec testovat, platí to jen pro případ, že později hodnotě nastavím null?

1. DEFAULTNÍ HODNOTY -------------------- ok, TEDY ŘENĚME, že už při vytváření nové instance objektu, budou nastaveny defaultní hodnoty, tedy každé volání konstruktoru způsobí iteraci nad všemi definovanými sloupci a nastaví defaultní hodnoty, tam kde mají být dosud jsem se bránil tomu, protože zpomalení při vytváření 25000 objektů bylo znát, ale to je asi stejně ojedinělý úkol a všechno něco stojí ? V tomto případě mi nastavení databáze a kombinace NULL a DEFAULT přijde nesmyslná? k tomu přece nikdy nedojde?

samozřejmě je nutné řešit validitu na úrovni modelu, ale bavím se tady o základní validitě, kterou může řešit už abstraktní třída objektu v orm, která k tomu ví všechny potřebné údaje (ví co může být empty, default, mandatory), samozřejmě validita je mnohem složitější, ale jde mi o to co ještě je potřeba ošetřovat za např. validním formulářem nette - jak jsem ale ukázal v příkladech, něco jako mandatory asi model ošetřovat bude muset, protože mysql to nedělá bame se ale o konkrétních věcech 1. defaultní hodnoty, měli by se tedy nastavovat už ve chvíli new Customer?tedy ihned po nějaké metodě setValues nebo podobně se nesetnute hodnoty nastavi na default? 2. mandatory - jak to myslíš, takový parametr by měl existovat ne? protože jak říkám mysql to neřeší (bohužel mandatory právě jde chápat několika směry a jedním z nich může být prázdná hodnota, kterou mysql dovolí zapsat i pro not null)

jak gettext tak moje navrhované řešení s asoc. polem umožňuje definovat libovolné množství pluralu, zapisuje se tam forma pluralu, tedy od X je to tato forma, od XY tahle atd. každopádně podle mne by to mělo stačit, v kolika jazykových verzích je linux? a používá gettext. samozřejmě nejzajímavější je japonština, protože tam se s počtem mění i pořadí slov a způsoby oslovení atd. pak by prý měla být zajímavá ruština, protože tam se to počítá nějak po desítkách, ale co se týče množství pluralu mělo by se to vejít do tří

Moje řešení, které navrhuji spočívá (a je to snad v článku uvedeno): 1. v centralizaci překladů v databázi (trochu ještě o úroveň výš co se týče správy) 2. centralizovaná verze umožňuje aktulizovat distribuovaným implementacím aplikace překlady a navíc je upravovat dle své libosti 3. při každé aktualizaci se automaticky vytvoří asociativní pole z databáze 4. měřil jsem to při 1000 překladech a nevidím sebemenší zpomalení, opět nedá se to měřit (samozřejmě sofistikovanými nástroji ano, ale pohybujeme se v desítkách milisekund - ani ne) 5. moje řešení i předestírá metodu, kdy se generuje gettext z dtb místo pole 6. stále nechápu to vyhledávání v databázi jsou pouze dvě metody: a. jedním dotazem si stáhnu celý obsah potřebných slov a vytvořím asociativní pole (jsem tam kde jsem byl) b. s každým překladem hledám v databázi, čímž se množí počet dotazů do dtb a to už je jiná pohádka, kterou jsme spolu už jednou řešili (stále trvám na tom, že transakční náklady na neustálé dotazování do dtb jsou vysoké) pochopte prosím, nechci si měřit pindíky, ale opravdu mi jde o nejvhodnější řešení za takové a takové situace, osobně už bohužel/bohudík nejsem běžným programátorem, který bere každou zakázku a tak bohužel/bohudík už nespatřuji tu koloritu každé jiné aplikace, ale už se soustředím pouze na určitý směr aplikací (proto nehledám řešení toho co řešit v příštích 10 letech nebudu, i když ocením když tady o tom bude zmínka a směr, kde se o tom dozvědět více), pojďme si říct pro co je jaké řešení vhodné a proč a pro koho a jestli vůbec se s tím můžeme setkat nebo alespoň více než 5% programátorů P.S.: gettext by měl být vhodný od 5000 překladů, jestli jeho vhodnost končí na 10000 nevím, ale bude někdy nekdo z nás řešit takovou aplikaci? stojí za to to usílí s optimalizací databází a hledáním řešení přes databáze? P.S.2.: mimochodem článek je hlavně o tom, jak řešit překlady aniž bych v budoucnu změnou metody si nějak ublížil

nešlo by reagovat na příspěvek, který naráží? :) nejsem si vědom, že já bych na někoho nějak narážel

dobrý ale není tedy databáze pouze určitá forma cache? přece vytváříš z dtb asociativní pole a moje navrhované řešení vytváří asociativní pole již jako kešovanou verzi php souboru kterou pouze includuji, viz ukázky ke stažení

ta databáze mi nejde pořád do hlavy :) vím že už jsme se na toto téma několikrát nepohodli, např. v článku http://www.webfaq.cz/clanek/Jeden-dotaz-do-databaze-nebo-tisice-je-to-stejne to jako myslíš, že pro každý překlad položíš jeden sql dotaz? tedy kvůli překladům např. 100x se zeptáš databáze na každé stránce? což nemusí být vůbec nic neobvyklého! nedokážu si představit, že je to rychlejší než asociativní pole