Vlastnosti objektu a lazy loading rubrika: Programování: PHP

Anonym
položil/-a 2.4.2014

Potřeboval bych poradit s řešením lazy loadingu dat do objektu, pokud ty data potřebuju už uvnitř objektu.

Mám databázový model. Do entity načítám data přes nějaký mapper který může nebo nemusí být nastaven (je nastaven pokud pracuji s entitou již existující v DB, není nastaven pokud vytvářím nový objekt entity, který teprve budu ukládat do DB). Tento mapper se stará o líné načítání hodnot. Zjednodušeně ta třídat vypadá nějak takto:

class Entity {
  // nemusí být nastaven, fungování mapperu nejde měnit!
  private $dataMapper;
 
  private $property1, $property2;
 
  // tohle je ve skutečnosti mnohem složitější, řídí se to anotacemi, vytváří vazby mezi entitamipříklad $book->author === BookEntity => AuthorEntity
  public function &__get($key) {
    if( $this->$key === null && isset(this->dataMapper) )
      $this->$key = $this->dataMapper->$key;
 
    return $this->$key;
  }
 
}

Potud dobrý. Problém je, že všechny property jsou nastaveny na null pokud se nezavolají přes magický __get($key). Tzn pokud mám ve třídě metodu třeba getProperty1State() která vrací třeba textovou hodnotu na základě nějakého integeru v databázi, tak to musím teď napsat takhle blbě

class Entity {
 
  ...
 
  public function getPropertyState() {
    if( $this->__get('property') == 1 )
      return 'Ano';
    else
      return 'Ne';
  }
 
  ...
 
}

Samozřejmě bych měl raději místo $this->__get('property') klasické $this->property nebo něco podobného.

odkaz
9 Vašek Ch.
odpověděl/-a 2.4.2014

Podobné problémy má každý, kdo si píše vlastní ORM :). Doporučuju zkusit Doctrine a mít víceméně po starostech, anebo se pustit do složité implementace vracení potomků entit, které mají tyhle metody vygenerované.

Komentáře

  • OndrejMirtes : Díky, že to nemusím psát. Tím, že v takto rané fázi začne tazatel používat Doctrine, ušetří nemálo snahy a peněz. 2.4.2014
  • Anonym : No zrovna Doctrine bych nedoporučoval, je to obluda co umí všechno, ale za jakou cenu... Něco "light" spíš. Kohanu ne, to je programátorský zlý sen, ale Yii, Fuel/CakePHP. Ev. mého favorita posleního měsíce - Phalcon, ale ten je spíše pro odvážné zkušenější. 3.4.2014
  • Kit : Doctrine jsem si vyzkoušel. Výsledek byl ten, že do konfiguráků jsem musel napsat zhruba tolik, kolik toho píšu do PHP. Úspora nulová. 3.4.2014
  • Vašek Ch. : Cpt.Nemo: No, tak schválně... Za jakou cenu? :-) 3.4.2014
  • Anonym : @Vašek Chromický: Aktuálně? 3x7500 bez DPH za nové disky. + škody způsobené na prodeji, čísla se pohybují v řádech desetitisíců měsíčně ... Takže tak. Server se procesorově fláká(40%), pamět využita na 30%, ale diskově to jde do kopru a to tam nejsou líné disky a jsou v RAID5. Jako jednoznačného škůdce jsem po dlouhém monitorování diagnostikoval Doctrine. 3.4.2014
  • Taco : CakePHP má šikovný DataMapper. Bohužel všechno je to o polích. A taky je to to jediné, co mě na něm zaujalo. 3.4.2014
  • Vašek Ch. : Cpt.Nemo: Takže si seš jistý, že kdybyste nepoužili Doctrine, finančně by vás suma peněz celkově utracených za vývoj a suma peněz utracených za hw vyšla lépe? S ohledem na všechny problémy, za které může skutečně Doctrine a které byste neměli, a s ohledem na odhad všech dalších problémů, které byste měli při použití něčeho jiného...? 3.4.2014
  • Anonym : @Vašek Chromický: Ano, jelikož i když je počáteční vývoj na Doctrine velice rychlý, jakmile se začne dělat něco složitějšího s DB, Doctrine rychle ztrácí dech. A hlavně, kolik zákazníků se k nám nevrátí, protože jsem měli pomalé odezvy/nákup se nepovedlo dokončit? Tohle jsou skoro ztráty, jejichž dopad právě smutně sledujeme ... Do toho problémy s Heureka atd ... Tohle není jen o ztrátách aktuálních, ale i budoucích a poškození dobrého jména ... Nechce se mě o tom psát, teď zase řeším další problém s Doctrine a používám sprostá slova ... Fakt je super, že Doctrine optimalizuje zpracování dotazů v transakcích .... 3.4.2014
  • Vašek Ch. : A teď otázka, jestli Nat píše druhou Heureku, víš ;-). V Bonami máme úplně opačnou zkušenost -- výhody plynoucí z rychlosti vývoje výrazně převyšují to, že bychom někde ušetřili pár stovek měsíčně za disky nebo ramku. 3.4.2014
  • pavel.stehule : @Cpt.Nemo - jestli se něco pro databáze nedoporučuje, tak je to RAID5! 3.4.2014
  • mkoubik : A dělali jste také kalkulaci jak by finančně vyšlo najmout někoho kdo tu doctrinu umí opravdu používat? Aneb "doctrine is not slowing your application down - bad programmers are". 3.4.2014
  • Anonym : mkoubik: A proč Doctrine všude vyChází jako jeden z nejpomalejších frameworků? Stačí si tročku zagooglit a najít si výsledky performance testů. A jenom podotýkám, já si Doctrine nevybral, eshop jsem zdědil po bývalém návrháři, kterého jsem nepoznal, protože krátce po spuštění nové verze eshopu odešel .... 4.4.2014
  • Anonym : Vašek Chromický : 6jader 64bitů na 2,1 GHz, 48GBRam, zvlášť disky na DB a eshopy. Kde jsme šetřili pár stovek? 4.4.2014
  • Kit : @Cpt.Nemo: Šetřili jste na počtu serverů... :-) 4.4.2014
  • Anonym : @Kit: Vypadá to tak ... :-( 4.4.2014
  • Anonym : @pavel.stehule: Dík za tip, tohle jsem nevěděl. V železe se nevyznám, na to jsou jiní lidé. Ale koukal jsem na hodnocení raidu a skoro žádný nedopadl dobře. Ještě budu muset nechat udělat srovnání READ/WRITE operací na disku a potom se rozhodneme jestli RAID5/RAID 0+1/ nebo mirror. http://www.perftuning.com/wp-content/uploads/2013/10/Overview-of-IO-Perf... Asi se odrazím s tohodle. 4.4.2014
  • Kit : Nejlépe vychází RAID10 nebo v případě více serverů RAID0 a zrcadlit servery. 4.4.2014
  • Anonym : Už na to jukám na wikině, zatím to vypadá na RAID10. Ale to bude jenom můj návrh. Jak se k tomu postaví správce ... 4.4.2014
  • Kit : Dřív se RAID10 tolik neprosazovalo kvůli ceně disků. Za ten nárůst výkonu proti RAID5 to však stojí. 4.4.2014
  • Anonym : Hmm Dell hlásí že doba dodání na naše disky 3 týdny, chjo .... Si dělaj prdel ... 4.4.2014
  • martin.tirsel : Mozno by nebolo zle popremyslat aj nad SSD diskami, tam je narast neporovnatelny, IOPS su nasobne vyssie, nez u klasickych diskov a DB pod palbou potrebuje prave toto. A potom este jedna drobna otazka - cachujete? 4.4.2014
  • maryo : Doctrine2 používám skoro denně asi 2 roky a rozhodně s ní nejsem spokojenej. Bohužel nic lepšího, co by vyhovovalo mym požadavkům, neznám. 5.4.2014
  • Taco : @maryo: Můžeš shrnout tyto požadavky? Ať vynikne rozdíl, o co vlastně jde. 5.4.2014
  • OndrejMirtes : Tohle vlákno mě dohnalo k napsání článku: http://ondrej.mirtes.cz/doctrine-2-neni-pomala 7.4.2014
  • Tharos : @OndrejMirtes: Hezky napsáno. Umožníš nějakým způsobem článek komentovat? :) 7.4.2014
  • OndrejMirtes : Tharos: Komentáře naschvál nemám, můžeš mi odpovědět na e-mail/Twitter/tady/vlastním blogpostem :) 7.4.2014
  • maryo : Taco: Požadavky mám víceméně na to, co Doctrine umí, proto jí používám. Je to ORM (já chci ORM). Neni to ActiveRecord, umí inheritance mapping, můžu si projít AST celý query a upravit jí. Což vyplývá z toho, že parsuje to DQL. Tj. můžu si např. definovat flastní DQL funkce který nezávisí vůbec na DB (Např. SELECT CURRENT_USER(), jen příklad). Nemusim extendovat žádnou magickou base entitu, je tam nějakej event system, inheritance mapping a spoustu dalších věcí. Nevím o ORM co by tohle všechno umělo. Natož mělo takovou komunitu jako má Doctrine. Ale že by byla Doctrine rychlá... Pomalá je hlavně "hydratace". To se projeví až když se selectuje hodně dat. Např. joiny ManyToMany to zabijou vždycky, i když samotnej dotaz trvá milisekundu. Ale tak je to celkem logický, musí přenášet obrovský množství dat, holt join víc jak jedný ManyToMany vazby neni vůbec dobrej nápad. Ale ona hydratuje miliardy hodnot a pak je zahodí (nejsou potřeba), optimalizovat by to určitě šlo dost. Co mě štve dost, je kombinace inheritance mapping a TO_ONE vazeb. Kdy v některejch případech Doctrine zná discriminator i ID, ale přesto není schopná vytvořit proxy entitu, prostě to zahodí). Taky mě trochu zaráží, zvlášť po tom, co člověk všude čte o SRP, SOLID apod. (někdy od těch samejch, co tu Doctrinu chválí), že Doctrina si s tim tolik hlavu neláme. Holt to neni malej projekt, už neni uplně mladej a každej má mouchy no, ale upravovat něco v kódu Doctrine, kdy UnitOfWork nebo BasicEntityPersister mají tisíce řádků, není úplně ono. Taky mě třeba moc nebaví řešit si ručně inverzní stranu. 7.4.2014
  • Vašek Ch. : Bylo by staršně fajn, milí downvoteři, kdybyste se vysvětlili. 8.4.2014

Pro zobrazení všech 6 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.