Názory k článku Entity beans v JBoss a relace
-
libor (neregistrovaný)Většina aplikací v Javě, které se dnes píšou, využívají objektově relačního mapování. Nevím co konkrétně vám připadá nafouklé a komplikované, mapování pomocí anotací (nebo xml) se provede jednou na začátku a ostatní kód je pak jednodušší, přehlednější a lépe udržovatelný než 'neobjektový' přístup při použití přímo JDBC API.
-
ivan (neregistrovaný)JJ, resit problemy s takovymi systemy je fakt lahudka. Obvikle to vypada tak, ze mi nekdo zavola a ma zadani: Nevime co vsechno jsme zmenili, nevime jake pouzivame indexy, nevime kteri uzivatele ted pouzivaji aplikaci, nevime co uzivatele v aplikaci delaji, nevime jake SQL dotazy nase aplikace provadi, nevime co vsechno zamykame a v jakem poradi, nevime kolik mame aktivnich sessions do DB, ale chyba je urcite na strane databaze a musite to rychle spravit. Takovehle technologie slibuji programatorum, ze nepotrebuji nic vedet o databazich. Bohuzel je to jen slib, ktery se neda splnit. Tohle se hodi jen pro male systemy s max. nekolika desitkami uzivateli.
-
ale az potom ako tie aplikacie zoptimalizuje niekto kto ma prehlad o zlozitosti algoritmov a datovych strukturach, a najma vie co sa za jednoriadkovymi prikazmi deje.
Klasicky pripada od nasich programatorov ( mapovanie Hibernate ).
if ( partner.getObjednavky().size() > 0 ) ...
V skutocnosti sa vykona toto :
- select * from objednavky where partner_id = ?
- java si vsetko poslusne natiahne do pamate ( List )
- a spocita pocet prvkov v danom zozname
-
Palo (neregistrovaný)Prave preto uprednostnujem fyzicky oddelenu entitnu/servisnu vrstvu. Tam si to jednak dokazem lepsie postrazit (menej programatorov ale skusenejsich) na webe nech sa chlapci hraju s farbami a okrajmi.
Za druhe ale predpokladam ze asi potom nieco s tym zoznamom robil takze to mozno bolo aj optimalne. Za dalsie uz pri navrhu nerobit relacie obojsmerne a ked tak opacne z objednavky na partnera. Potom im to uz dojde ze musia pouzit nejaku sluzbu ktora sa da mozno optimalizovat.
Ale inac pekny bordel. -
Prave preto uprednostnujem fyzicky oddelenu entitnu/servisnu vrstvu
Pridavanie dalsich a dalsich vrstiev iba zneprehladnuje aplikaciu. Ja som netvrdim, ze ER mapovanie (Hibernate) je zle. Ja sa stazujem, na nevedomost programatorov, ktori si o sebe vela myslia ale v skutocnosti toho malo vedia.
Za druhe ale predpokladam ze asi potom nieco s tym zoznamom robil takze to mozno bolo aj optimalne
Ani nahodou, nemaju ziadne zabrany, bez problemov si napchaju do pamate sto tisic zaznamov, len aby zistili ci existuje nejaky.
Inak Hibernate poskytuje atribut, ktory umozni namiesto nacitania vsetkych entit do pamate urobit iba "select count(*) from objednacky where partner_id =?".
Za dalsie uz pri navrhu nerobit relacie obojsmerne
Zly napad, nezadefinovanim obojsmernej relacie v entitnom modeli si znemoznim vytvarat dotazy cez HQL ( Hibernate Query Language ).
Na tento problem mam zatial jedine riesenie : Dat vyvojarom tak velku DB, aby taketo hluposti nemohli prehliadnut a neustale robit reviziu kodu.
-
ivan (neregistrovaný)To je presne ono. Koho dneska zajima jaky je rozdil mezi "select * from" a select "count(1) from"?
Java neni spatny jazyk ale nema zadnou podporu pro paralelismus a zamykani(narozdil treba od archaickeho pl/sql) Tyhle programy jsou vyvijene jako jedno-uzivatelske a podle toho taky funguji. Ze zdrojaku takovehle aplikace se da tezko odvodit co se bude dit v databazi a jakym zpusobem potom databaze ovlivni ostatni uzivatele. -
Palo (neregistrovaný)
Java neni spatny jazyk ale nema zadnou podporu pro paralelismus a zamykani
Si robis srandu. Nepoznam jazyk ktory obsahuje tolko moznosti pre zamykanie a paralelizmus ako ma Java. Od low level java.util.concurrent.atomic az po high level struktury java.util.concurrent a java.util.concurrent.lock. Tam je uplne vsetko. Nie som taky dobry v PL/SQL, ako si tam zalozim dalsi thread? -
Palo (neregistrovaný)A to si si z coho vylozil, z kariet? Ivan nehovori nikde o transakciach ani o isolation level. Ja ti poviem ze je vela programatorov ktory neovladaju ani Javu a to myslim veci ako genericke typy ich pouzivanie, nerozumeju zakladom objektovej dekompozicie, patternom, ktore v pl/sql pre istotu ani nemate a nemozte ich urobit.
Isteze kazdy by rad robil v teame samych profesionalov a nemusel sa pozerat ako niektori programatori koduju v style ktoremu ja hovorim "coding by accident". Najlepsie je napisat nazov nejakej suvisiacej premennej, buchnut tam bodku a stlacit CTRL+medzera. Potom si vyberu co sa tam najviac hodi, postup opakuju kym nie su spojny a idu dalej.
Ja robim vela z architekturami systemov, isteze musis mat v time niekoho kto sa v tom vyzna to ale neznamena ze KAZDY to musi vediet. Mas ludi ktory sa vyznaju vo frontendoch, Script enginoch, rule enginoch, BPML, SOA. Praca s DB nie je zas az taky science ako si myslite. Je to dolezite ale su to obycajne kazdodenne problemy projektu.
Mate programatorov ktory programuju frameworky, mapovanie do DB a niektori citaju specifikaciu a snazia sa to cele najako pochopit a pozliepat dokopy. To su problemy velkych projektov. Male projekty dajte robit radsej niekomu kto sa v tom naozaj vyzna.
Ja som pracoval na projekte kde sme aj v dev prostredi zriadovali stlpce v tabulkach cez DB specialistu ktoremu sme posielali dobre ze nie rovno SQL ktore sme si nemali ani kde vyskusat a ten imbecil bol schopny po dvoch dnoch vam to vratit ze tam chyba ciarka. Naco je taky DB specialista.
Nejako som sa rozpisal len som chcel povedat ze kazdy nieco vie a niektori nevedia nic a neurobite s tym obvykle nic lebo s nimi musite zit na projekte a v tom je to umenie vychadzat s ludmi. -
A to si si z coho vylozil, z kariet? Ivan nehovori nikde o transakciach ani o isolation level.
Pretoze to je klasicky pripad pohladu DB-specialistov na problemy paralelizmu. Je to proste ich uhol pohladu.
patternom, ktore v pl/sql pre istotu ani nemateOoops, pattern je navrhovy vzor, a ako taky moze byt pouzity v lubovolnom programovacom jazyku. Neprogramujem v pl/sql, ale ani si nedovolim nan nadavat. Rovnako nechvalim Javu do nebies. Bud niekto programovat vie, a potom je jedno v akom programovacom jazyku robi, alebo programovat nevie a potom je jedno ake programovacie jazyky ovlada.
Praca s DB nie je zas az taky science ako si myslitePokial vsetko funguje, a DB sa vojde do pamate, tak nie je problem. V momente ak DB narastie cez 1TB a pripajaju sa stovky pouzivatelov, tak je sakra dolezite ako je to napisane.
kazdy nieco vie a niektori nevedia nicsuhlas.
a neurobite s tym obvykle nicnesuhlas. Je treba robit osvetu, skolenia, reviziu kodu, unit-testy, integracne testy. A pokial sa takyto "programator" nechce/nevie naucit ako to ma robit, tak sa s nim rozlucim.
-
Palo (neregistrovaný)
Ooops, pattern je navrhovy vzor, a ako taky moze byt pouzity v lubovolnom programovacom jazyku.
Nie celkom, ak ti chybaju zakladne mechanizmy ako polyformizmus alebo riadenie threadov (ako napr v PL/SQL) tak ten pattern neurobis. Existuju objektove patterny ktore v struktorovanom jazyku neurobis.Pokial vsetko funguje, a DB sa vojde do pamate, tak nie je problem. V momente ak DB narastie cez 1TB a pripajaju sa stovky pouzivatelov, tak je sakra dolezite ako je to napisane.
Teraz ma tu vsetci zabijete ale my sme raz mali vykonostny problem na aplikacii a bolo lacnejsie prikupit server ako to optimalizovat aj ked som bol proti. Cost efektivita nepusti. Samozrejme ze je dolezite ako je to napisane ale pomocou roznych nastrojov sa da zistit kde ti to koliduje alebo dlho trva. Tu sa da v Java pekne vyuzitelne AOP a na cas si nainjectovat kod nejakym performance aspectom. Ale inac suhlas.nesuhlas. Je treba robit osvetu, skolenia, reviziu kodu, unit-testy, integracne testy.
Pokial to robis v domovskej firme tak OK. Zaujimavejsie je ked sa zide particka najomnych zoldnierov s 5tich roznych firiem plus domaci stuff a zacne sa robit 1.5 rocny projekt. Skus o niekom povedat ze je blbec a potrebuje skolenie. Zacnes byt ako nekooperujuci prvok vytlacany nech si ako chces dobry. Na takychto projektoch rozhoduje kto si a koho mas za sebou nie co vies. A k tomu politicka pretlacania jednotlivych firiem. Proste lahodka. -
ivan (neregistrovaný)Jo presne tohle jsem myslel. Samozrejme ze vim ze java ma vlakna, zamky a vubec vsechno co takovy jazyk ma mit. Problem je v tom, ze si mnoho programatoru neuvedomuje, ze tim ze se pripoji k nejake databazi ovlivni praci tisicu uzivatelu, kteri pracuji s tou samou aplikaci. Kdyz v jave napisete "a.b=1;"
tak z toho nemate jak odvodit co se bude dit v databazi a hlavne nevite kolika uzivatelum znemoznite praci. Kdyz to porovnam se zastaralou, nemoderni architekturou klient-server (treba Oracle Forms)
tak muzu treba zjistit ze: "Uzivatel Vomacka, prihlaseny z PC JVOM pouziva modul aplikace XY, ma zamcenou radku v tabulce ABC a tim blokuje uzivatele Ruzickovu v modulu YZ". A cele mi to zabere asi 20 minut. Kdyz neco podobneho resim na aplikaci bezici na websphere tak to mam minimalne na tyden. To je pak mnohem jednodussi kazdou pulnoc spustit "killall java". Casto se stane, ze se chyba v aplikaci projevi v databazi. Kdyz ale tu databazi abstrahujete a nemate jasnou predstavu o tom co po te databazi vlastne chcete, tak se ty chyby velice tezko resi. -
pavel (neregistrovaný)Relace, které mají na druhé straně N (tj. 1:N a M:N) se standardně načítají lenivě (viz specifikace, kapitoly 9.1.24 a 9.1.26). U vazby M:N je to dále v článku uvedeno, nicméně příklad s lenivým načítáním 1:N mi připadá matoucí (protože je to default).
Dále ještě doplním, že pokud bude velké množství relací fetchované eager, tak se v horším případě může stát, že se do paměti natáhne celá DB. V lepším případě se natáhne "pouze" velký strom objektů. Proti tomu se při použití JPA implementace v Hibernate lze bránit nastavením maximální hloubky, do které se rekurzivně entity fetchují eager (parametr hibernate.max_fetch_depth). Kromě toho je vhodné se zamyslet nad tím, jestli je skutečně potřeba vše fetchovat eager.
A ještě postřeh z používání JPA implementace v Hibernate. Eager fetch mi vždy fungoval pouze pokud jsem loadoval jedinou entitu (např. pomocí EntityManager.find nebo pomocí lenivého fetche relace N:1). Ve všech ostatních případech (např. dotaz vracející kolekci entit nebo lenivý fetch relace 1:N) byl load navázaných entit vždy lenivý bez ohledu na nastavení anotací. V případě dotazů to lze obejít pomocí fetch joinů, ale pozor na to, že potom může dojít k duplikaci záznamů. Nevím, jestli popsané chování je bug nebo feature, ve specifikaci jsem to nehledal, ale připadá mi celkem logické. -
Palo (neregistrovaný)Zalezi ako velmi Enterprise to mate vyriesene. Pre male riesenia kde mate Webovu vrstvu pokope s entitnou v jednom virtualnom stroji je to OK. Ale pre velke enterprise riesenia kde mate skutocne entitnu/servisnu vrstvu separatne je lazy loading dobry iba pre sluzby, web uz si ich lazy nanataha. Taktiez pre riesenia s ESB (SOA) lazy velmi nepomoze.
-
antaran (neregistrovaný)RE:
V případě dotazů to lze obejít pomocí fetch joinů, ale pozor na to, že potom může dojít k duplikaci záznamů. Nevím, jestli popsané chování je bug nebo feature, ve specifikaci jsem to nehledal, ale připadá mi celkem logické.
Ahoj
Nie je my jasne preco dochadza k duplikacii zaznamov pri fetch joine???
(k duplikacii akych zaznamov? preco ti to pripada logicke?)
nejaky priklad by som odcenil...
Diq
ant -
pavel (neregistrovaný)
Pomůžu si citací ze specifikace (kapitola 4.4.5.3):
The following query returns a set of departments. As a side effect, the associated employees for those departments are also retrieved, even though they are not part of the explicit query result. The persistent fields or properties of the employees that are eagerly fetched are fully initialized. The initialization of the relationship properties of the employees that are retrieved is determined by the metadata for the Employee entity class.
SELECT d FROM Department d LEFT JOIN FETCH d.employees WHERE d.deptno = 1A fetch join has the same join semantics as the corresponding inner or outer join, except that the related objects specified on the right-hand side of the join operation are not returned in the query result or otherwise referenced in the query. Hence, for example, if department 1 has five employees, the above query returns five references to the department 1 entity.
Za popsaných podmínek tedy tento dotaz vrátí 5 departmentů (5 krát ten samý), přestože department s číslem 1 existuje pouze jeden. Bez použití klauzule
LEFT JOIN FETCHby se vrátil jediný záznam. Zaměstnance by bylo defaultně nutné dotáhnout lenivě.Citovaný text zároveň říká, že při vyhodnocení dotazu se korektně dotáhnou relace podle nastavení v anotacích. Mnou popsané chování Hibernate tedy pravděpodobně byl bug nějaké starší verze. Zkoušel jsem to znovu a nyní se skutečně Hibernate chová v souladu se specifikací, takže se omlouvám za mystifikaci.
A proč mi to připadalo logické? Protože mám možnost si explicitně referencované entity dotáhnout pomocí fetch joinu, pokud to potřebuji, nebo je nedotahovat, pokud to nepotřebuji. Automatické dotažení entit nemusí být vždy efektivní. Např. pokud ve výše uvedeném příkladu budu mít Employees dotahované eager, tak Hibernate udělá jeden dotaz na Department a potom bude postupně dotahovat Employees po skupinách o velikosti
hibernate.default_batch_fetch_size. Počet dotazů do DB je tedy lineárně závislý na počtu instancí entity Department. Tohle se žádnému DBA líbit nebude... Pokud se budou Employees dotahovat lenivě, tak se provede to samé, ale až při prvním přístupu ke kolekci Employees. Pokud tedy logika aplikace pracuje pouze s Departmenty, tak stačí jediný dotaz do DB.
ČLÁNKY DO MAILU