seš si jistý tím že datum se přepíše? zkoušel si? nevím jestli verze mysql se chovají jinak, ale mám za to že se mi nezmění v případě že se nezmění data jinak s triggerem mám právě ten problém co povídáš, představ si že děláš dump, měníš název databáze nebo něco podobného, replikuješ data atd. tak právě potřebuješ tomu sloupečku vnutit ten čas, chci zachovat původní čas ne všude aktuální

Jedná se konkrétne o nejběžnější aplikaci se kterou se programátor může setkat, a to je expedice balíků, dosud pošta toto řešila softwarem Pošta2002, kde bohužel smlouvy byly postaveny tak blbě, že pošta svým obchodním partnerům nedokázala nabídnout alternativu a licence na tuto aplikaci skončila. Pošta k tomu nabídla webové rozhraní, které nejen po více než půl roce není stále dokončené, ale je neustále nefunkční (neustále se objevují různé problémy), jelikož partneři jsou na tento systém odkázáni a potřebují ho využívat denně, obvykle terčem stížností se stane programátor, který řeší nějakou komunikaci s touto aplikací, byť s nefunkčností celého systému nemá nic společného. Problém je tak palčivý, že ten kdo se s touto aplikací setkává jistě ví o čem je řeč. Základní chyba byla, že pošta na podobnou věc nenajala odborníky, ale dokonce snad podle všeho řeší vývoj aplikace interně. Práce s aplikací vypadá tak, že pracovník co každý den expeduje balíky, zjistí cca hodinu před příjezdem svozu, že je v aplikaci opět nějaký problém, místo aby tedy pracoval, řeší hodinu jak obejít nedostatky aplikace nebo čeká jestli se aplikace rozjede.

když něco budu platit tak to asi nebude open source ne? jinak sorry článek spojuje více věcí v jedno a tak ani z tvého příspěvku není zřejmé na co reaguješ (chyba článku) shrňme to takto - open source je něco na co se nelze spolehnout a je velice nebezpečné na něčem takovém založit business (neexistuje zoodpovědná osoba), - google je něco co vytváří trh, který jen stěží lze ignorovat, ale zároveň podmínky jsou velmi nerovnocenné pro zůčastněné strany, - poslední malý topic je opět o rovnocennosti zůčastněných stran, obchodní vztah mezi nerovnocennými a různě velikými partnery je s velkou pravděpoodbností narušen už v základech z principu věci

tak ono v některých případech to jinak nejde, např. rozbalování 7gz archivů, zjišťování velikosti adresáře by bez toho bylo v mnoha případech nepoužitelné (nebo php snad něco takového umí? nemuselo by projít všechny soubory a sečítat jejich velikosti? = nereálné) ale samozřejmě běžné operace nepotřebují exec, asi by stačilo si to upravit aby přidané fce byly zakázány, např. vypnout archivy, apod.

Ke které části textu se reakce vztahuje? Btw. to o čem mluvíte je hezké, ale ještě nikdy mi google peníze nevrátil za podobné prokliky, které popisujete. Ale nerozvíjejme flame o tom, jak google nemá žádný support nebo o tom jak "kontaktujte nás" na stránkách google se ztratilo v překladu a všechny pokusy o kontakt vedou na rozsáhlý faq.

myslím, že je to celkem zajímavý nápad, on ale je problém jen vůbec se samotnou represí seznamu, on prostě ze zbozi.cz žije a stěží se dá představit, že si odstřihne platícího zákazníka, nicméně za chvíli nebude chtít nikdo platit, protože všichni ze zbozi.cz utečou a nebude mít návštěvníky (myšleno s nadsázkou ono 10% odliv pro něj zas tak moc neznamená) otázka je, jestli jiné portály to mají jak řešit, umí to řešit? heureka, hledejceny apod.? opravdu je znatelný odliv uživatelů na tyto portály?

netbeans bohužel nemá :( nebo jsem to alespoň nenašel a detekovat kódování co vím, také neumí, detekuje na základě kódování projektu jinak jde o to, odhalit tuto hlavičku v sadě stovek souborů, což by s editorem mohl být trochu problém 2B vs. 3B zkusme třeba wikipedii http://en.wikipedia.org/wiki/Byte_order_mark#Representations_of_byte_order_marks_by_encoding

pletu se nebo to nebude fungovat? 1. ano, první dva kroky by mohla nahradit fce autoUTF od dg nicméně spoléhá jen na dvě kódování což by nemusela být pravda 2. DOM pozná kódování podle charsetu v meta tagu, proto, by se měl nahradit, ale ani to není spolehlivé, proto byl přidán ještě bod 5

s tímhle bych docela polemizoval, skoro to vypadá jako příspěvek deredesu? mám obavy, že deredes nedokáže vysvětlit ani podloženou a podepsanou směnku nehledě na provizi 50%. nevysvětlili mi krom otravování mailem (případně poštou) v čem ta služba spočívá

záměrne v článku uvádím náklady minimálně dopředu domluvené (tedy před koupí = doprava = cca 99Kč)! ze zkušenosti desítek obchodů sleduji, že zákazníci spíše jsou tak drzí, že do telefonu řeknou však je to v pořádku, stejně bych zboží mohl do 14 dnů vrátit, a o nějaké nutnosti platit dopravu nechtějí slyšet, tento trend vidím, ale spíše v poslední době, nevím jestli krize dělá z lidí nezodpovědné barbary nebo jeslti krize přivedla na internet ty klasické české vychcánky, kteří dosud internetu nevěřili a tak přece na něčem tak nespolehlivém, kde je to samý zloděj, nebudou nakupovat

že by to tak nebylo v době psaní článku? víme? více fištrónu občane ČR, víme? nebo, že by tolik lidí problematiky určitě lépe znalých než vy toho nevšimlo?

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á?