- Hamarosan megkezdődik a nubia 2,8K-s táblagépének szállítása
- Barátokká váltak az eddig rivális AI-óriások
- ASUS blog: Ideális olcsó utazós gép lett az új Vivobook S14
- Az Aura Displays hordozható monitorhármasa jól felturbózhatja a produktivitást
- Dual Mode-os IPS monitorral adott magáról életjelet a Gigabyte
- Vezetékes FEJhallgatók
- HP notebook topic
- Kormányok / autós szimulátorok topikja
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- ASUS notebook topic
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- OLED TV topic
- Hisense LCD és LED TV-k
- HiFi műszaki szemmel - sztereó hangrendszerek
Új hozzászólás Aktív témák
-
Cathfaern
nagyúr
Ha logikailag egy alkalmazás (pl. nyilvános oldal + annak admin felülete), akkor nem sok értelme van. Ha valami cross-site login dolgot akarsz (pl. van egy már elterjedt oldalad, sok felhasználóval, és akarsz csinálni egy teljesen mást, de közös bejelentkezést akarsz), esetleg akkor lehet értelme a különvételnek.
-
n00n
őstag
Van egy Webapp1 nevű servlet, ezen vannak statikus html oldalak, illetve egy login form. Ha jó a felhasználónév, jelszó, akkor egy teljesen új felület jelenne meg. Ezt úgy tudom új projektbe illik megírni.Ezt is kiexportálom .war-ba. Akkor hogy tudok az egyik warból a másikra hivatkozni? Remélem érthető.
-
n00n
őstag
Sziasztok
Elkezdtem ismerkedni csak úgy hobbiból a Springgel. Össze is raktam egy Spring MVC webappot. Kiexportáltam .WAR fájlba felraktam egy szerverre (Tomcat 7) és nagyon szépen megy. Viszont azt, hogy tudom megoldani, hogy ebből a webappból "indítok" egy másikat? Hogy tudok ráhivatkozni? Próbálok rákeresni angolul, de nem sok sikerrel...
-
whatnot
őstag
Sajnos nem találok a java üzemeltetés részével kapcsolatos témát, így itt tenném fel a kérdésemet.
Van ötletetek, hogy a java mitől gondolhatja meg egyszer magát csak úgy és vált időzónát? Pl. CEST -> GMT+1 ? Anélkül, hogy bárki is hozzányúlt volna, ráadásul ez több gépen is, de nem mindegyiken.
-
MrSealRD
veterán
Hasonló jellegű élményem már volt. Akkor AWS-ben műkő oracle-be írtam pl/sql-t és viszonylag sok variálás volt... és a sok kis másodpercből akkora késleltetés lett, hogy inkább lehoztam local-ba mert elfogyott a türelmem.
150-200 mag...az szép...gondolom ott aztán kétszer meggondoltátok mielőtt rányomtatok a fordításra...
-
válasz
MrSealRD
#6285
üzenetére
Nem arrol van szo, hogy nagyon hosszu lenne a forditasi ido, csak folyamatosan rebuildelek, mert kiserletezem valamivel -- viszont a hotswap bizonyos okok miatt nem mindig mukodik. Ergo ha valamin valtoztatok, akkor varnom kell kb. 15 masodpercet, amig latom az eredmenyet, es ez most sok (mert rengetegszer kell varialni -- nem is azzal van gond, hogy sok idot elvesz, csak idegesito -- olyan, mintha egy mobilon akadozna az UI).
De ugy latom, kicsit megvarialom a workflow-t, es atallok REPL-re.
(Amikor C++-t csinaltam, ott volt akkora (ill. olyan szenne template metaprogramozott) projekt, hogy a projektben resztvevo osszes ember desktopja egyben compile szerverkent is funkcionalt, es amikor valaki forditott, akkor egyszerre kapott kb. 150-200 CPU magot, es igy tartott negyed oraig. Ja, es az IntelliSense nem mukott az IDE-ben, tehat siman benezhettel egy zarojelet valahol, es akkor a negyed ora vegen kaptal egy hibauzenetet, hogy itt hianyzik egy zarojel, forditsd ujra. Egyebkent meglepo, hogy meg lehet szokni azt, hogy preciznek kell lenni, amikor gepelsz. Az IntellIJ meg kabe elore megmondja, hogy ot perc mulva milyen nevu konstruktorparametert szeretnel, es felajanlja
) -
válasz
MrSealRD
#6279
üzenetére
Dehogy alantasabb, en csak annyit mondtam, hogy ha szorakoztato feladatot akar ES van ra lehetosege, akkor erdemes mast nezni. Mashogy mondva: kevesebb embert erdekelne hobbibol a J2EE, mint mondjuk a dronvezerlo algoritmus
Ettol meg irtozatosan elterjedt es sikeres dolgok ezek. -
bucsupeti
senior tag
nem tudom ismeritek-e, de jó kis szórakozás és tanulni is lehet belőle: http://www.codewars.com/
Eddig nem volt benne Java, de most végre bétában betették! Lehet feladványokat is csinálni, vagy mások feladványát megcsinálni. Ha valamit sikerült megoldani, akkor mások megoldását is meg lehet nézni. Ebből pedig sokat lehet tanulni. -
A Scala meg a JavaEE szerintem nem fuggenek jobban ossze, mint barmilyen mas Java-s technologia. Ha a Scala ennyire tetszik, akkor nezd meg az extrem oldalat, pl. a Scalaz-t. Ha most jonnek ki az egyetemrol, akkor tuti megprobalnam elkerulni a Springet meg a J2EE-t, ennel sokkal erdekesebb dolgok is vannak a vilagban, es penzt keresni massal is lehet.
-
raggg
senior tag
Szerintem egy erős Java tudás mellett némi Spring || EJB / Hibernate tudás elegendő. Voltam már olyan interjún, ahol komolyan belekérdeztek a frameworkökbe, de azért szerintem nem annyira jellemző (legalábbis én kevésbé tapasztaltam eddig). Ahol komoylabban belementünk, ott pedig éppen olyanról kérdeztek, amiről előtte mondtam, hogy dolgoztam vele.
Amit azért érdemes megnézni/megtanulni, hogy egy-egy konténer hogyan működik, miért úgy, vagyis a mögöttes tudást elsajátítani (erre mondjuk nagyon jó a hivatalos Oracle anyag szerintem).
Tehát röviden: ha az alapok megvannak (koncepcionálisan) akkor nem hiszem, hogy aggódnod kellene.
A maven azért elég "alap", érdemes elsajátítani. Ha rajtam múlik, én azt használok Gradle helyett is.
Scala azért ahogy én látom elég sok helyen csak kiegészítő technológia, sajnos megvannak a maga zsákutcái, de csak támogatni tudlak!
-
Lacces
őstag
Hali!
Lenne egy kérdésem, hogy az álláspiacra egy junior / beugró szinten mit kell tudni a JavaEE-ből? (Miket érdemes megtanulni?)
Egyetemen JavaSE ment. Alap elméleti szintem van a JavaEE, szóval tudom, meg nagyjából a JSP, JSF, de gyakorlati szinten sosem szagoltam hozzá.
OOP nem akadály, igaz, hogy melóban PHP-ban van 2,5 tapasztalatom, de Symfony2 keretrendszer (PHP-s)-ról nézegetve az alap JavaEE-t úgy a mögötte lévő HTTP filozófiát könnyű felfognom. Plusz pár hónapja átdobtak a .NET csapatba, ahol Asp.net MVC megy. Szerintem innen a JavaEE-re átállni nem lehet nagyon nehéz. (Git, TDD, Scrum, demozás, verik belém a németek)De csak alap szinten tényleg csak a szükséges szintet akarom megtanulni (de az nem tudom, hogy micsoda, EJB, JDBC, esetleg a Hibernate is kellenne?) Mely könyveket érdemes nézegetni.
Azért akarom az elégséges szintet, mert a Scala sokkal jobban érdekel, igaz nehezen tanulom most (van online kurzus) de nagyon motivált vagyok benne.
És ahogy nézegettem a Scala álláshirdetéseket, Scala együttjár a JavaEE. És ezért akarok csak egy "elégséges szintet tudni". Nektek mi a véleményetek erről?
Mondjuk lesz egy olyan Androidos kurzus folytatás, ahol a szerver oldali részét nézik meg és SpringMVC-vel fognak dolgozni, talán arra még érdemes energiát és időt szánnom.
Meg Maven-t már nem nézném át, inkább csak Gradle-t használnék helyette.PHP-t már kezdem kinőni (néhány hobbi projekthez jó) Ruby on Rails-sel elhelyezkedni nagyon nem lehet, max csak Seniorként, Java és C# hosszabb távon nem érdekel. Scala az ami érdekel (már egyetemen is megfogott a Prolog), a Hadoop, na meg a C++ linux és beágyazott rendszerekhez. (De Scala és a Hadoop páros az ami motivál)
Python sem rossz, de nem tudnék benne hobbi projektet fenntartani. -
#6275
emvy
félisten
WonderCSabo
#6274
válasz
WonderCSabo
#6274
üzenetére
> megőrjítene
Jah, kell egy kis ido, amig az ember atall - erre mondtam lent, hogy legalabb megprobalni erdemes, mert jobb fejleszto lesz beloled, ha tobb oldalrol is megnezed ugyanazt a problemat.
Kiszerkesztetted valami miatt a peldad, de ha ujra visszarakod, elmondhatom
(egyebkent ennyi: (range 1 5)). -
boost
veterán
"console.log(i++) nem ugyanazt logolja mint
console.log(++i)"Ezt én értem, ezért is nem értettem, hogy miért ++i-t használnak a for ciklusban, de elolvasva a doksit most már látom, hogy az ++i, vagy az i++ csak a statement végrehajtása után hívódik meg, utólag. Azt hittem már korábban meghívódik. (Végiggondolva amit én gondoltam, az nem is logikus. ) Ilyen szempontból tényleg mindegy, hogy a for ciklusban ++i vagy i++ van.
Remélem nem írtam nagy nagy hülyeséget.
-
#6272
Aethelstone
addikt
floatr
#6270
-
floatr
veterán
Ha a krém a továbbiakban is hasonlóan akarja megoldani az 5-10%-ot érintő problémákat, ahogy eddig, akkor annak sokan nem fognak örülni. Minden egyes alkalommal, amikor valami forradalmit pakoltak bele a java-ba, vagy szabványosítottak valamit, mindig elővettek valami alapot (loptak), amiből ki tudtak indulni, és a végeredmény egy teljesen elborult, butított, kompromisszumos szutyok lett, de legalább tudományos volt, mintha egy egyetemi tanár akarta volna az élete oktatási anyagát összerakni.
A másik probléma, hogy a java-ba az eddigi koncepcionális újítások legtöbbször zavaróak voltak, és ha haladni is akartál volna vele, akkor a framework-ök tartottak vissza. Sajnos, vagy sem - tudomásul kéne venni azt, hogy a java nem nyelvi bravúrkodások miatt kapott eddig is ekkora hangsúlyt, hanem a rengeteg framework miatt.
-
Jim-Y
veterán
Csak speciális esetekben van különbség a kettő között. Én postfix szoktam használni mindig, de eddig se elonyom, se hatranyom nem származott belőle. Pl javascriptben
console.log(i++) nem ugyanazt logolja mint
console.log(++i)
Előbbi kiirat majd inkremental, utóbbi inkremental majd kiirat. Javascriptben az automatic semicolon insertion miatt lehet talán érdemesebb a postfix et megszokás, de ezek ezoterikus esetek. -
#6268
emvy
félisten
Aethelstone
#6260
válasz
Aethelstone
#6260
üzenetére
> "szakma krémje"
Azt irtam, hogy a szakma kremje dolgozik ezeken a problemakon, ezert valoszinuleg a problemak valosak.
-
#6267
emvy
félisten
WonderCSabo
#6266
válasz
WonderCSabo
#6266
üzenetére
Na, ez egyelore nem ment at.
NEM lehet felulirni semmit, mert a visszaadott lista is immutable. Azert mukodik az egesz, mert csak immutable (megvaltoztathatatlan) listaid vannak.
-
#6265
emvy
félisten
WonderCSabo
#6264
válasz
WonderCSabo
#6264
üzenetére
Nem kell, pl. a lancolt lista vegulis nem mas, mint egy head elem. Tehat pl. egy 'rest' fv. annyit csinal, hogy elorelep egyet, es az lesz a masodik lista. A defensive copy az vegulis egy kenyszermegoldas, es pont jo pelda a mutable objectek problemajara.
Szoval ha van egy vektorod, ami a memoriaban az X es X+k kozotti helyet foglalja el, es egy fuggveny ebbol kiveszi az elso elemet, es visszaadja a maradekot, akkor a visszaadott vektor X+1 es X+k kozott lesz -- defensive copy eseten lemasolod az egesz vektort valahova, es az arra mutato referenciat adod vissza.
Persze ezek implementacios kerdesek, a lenyeg, h feltetelezheted, hogy az immutable kollekciok eleg jo teljesitmenyuek.
-
Nem hagyja ki -- mindketto pont ugyanugy mukodik. A for loop harmadik resze egy kulonallo statement, ami eloszor vegrehajtasra kerul, es UTANA ertekelodik ki a kilepesi feltetel. Akkor lenne kulonbseg, ha a kilepesi feltetelben inkrementalnal, pl:
for i = 0; ; i++<10; // i = [0,10]
for i = 0; ; ++i<10; // i = [0,10)Viszont a lenti esetben tok ugyanazt fogja csinalni, pont ugyanolyan sebesseggel. C/C++-ban van kulonbseg, mert a prefix operator un. rvalue-t produkal, a postfix pedig lvalue-t. Elobbi gyorsabb par orajellel, ezert ha tenyleg csak inkrementalni akarsz, akkor ++i-t szokas hasznalni. Java-ban tehat nincs semmi kulonbseg.
-
#6262
boost
veterán
Aethelstone
#6261
boost
veterán
válasz
Aethelstone
#6261
üzenetére
De miért ++i? Kapásból ki is hagyná az első elemet, ha pl egy listán, tömbön fut végig
-
#6260
Aethelstone
addikt
emvy
#6254
-
#6259
emvy
félisten
WonderCSabo
#6258
válasz
WonderCSabo
#6258
üzenetére
Egy trivialis megoldas a copy on write es hasonlok. Egy pelda: funkc. nyelvekben nagyon jellemzo, hogy listakat hasznalunk adattarolasra -- most a lenyeg, hogy ertekek vannak egymas utan, nem az, hogy most vektorrol vagy lancolt listarol van szo. Ha pl. van egy olyan fuggveny, hogy 'rest', ami visszaadja a lista osszes elemet, kiveve az elsot, akkor ugye a fuggvenyhivas utan van mar ket listad: az eredeti meg egy masik, ami pont ugyanolyan, csak epp hianyzik az elso eleme. Az implementacio nyilvan okos, es nem fogja lemasolni a listat, az uj lista siman ugyanazokra az elemekre mutat, csak epp eggyel kesobbrol kezdi. Mivel az elemek ugyebar immutabilisak (nem irhatok), ezert ez teljesen biztonsagos, es gyors is.
A lenyeg, hogy alapesetben nem irsz felul semmilyen olyan erteket, amit valaki mashol meg hasznalhatna. Ha van egy erteked, az valtozatlan marad orokre. Tehat pl. nincs olyan, hogy for i = 0; i<10; i++ -- ilyen eszkozoket nem hasznalunk altalaban.
-
boost
veterán
Tetszik, én már keveset programozok, most több bigdata projektem volt idén, és mivel úgy néz ki a spark elég komoly játékos lesz e téren (amit egyébként Scalaban programoztak, és abban is kell használni) nekiugrottam.
Nekem tetszik. Eltérően más kurzusoktól, ahol elég meghallgatni a két órás anyagot, és megérted mi a feladat, itt tényleg komolyan utána kell olvasni a könyveknek. A fősulis elektrotechnika tanáromra emlékeztetett, aki sosoe adott ahhoz hasonló feladatot ZHn, mint amihez hasonlót órán leadott, ezért simán 80-90%-os arányban irogattuk a karókat.
Faszi érthető, amit hiányolok azok a quizek. Az Android kurzuson sokat dobott a megértésen. MIre átrágtam magam a Quizen, már megjegyeztem az alaptananyagot. De az R kurzus is ilyen volt.
-
#6254
emvy
félisten
Aethelstone
#6253
válasz
Aethelstone
#6253
üzenetére
Nem hinnem
-- eleg intenziven foglalkozik ezekkel a szakma kremje az utobbi evtizedben, par apro dolog meg a Java-ba is beszivarog (lasd Java 8). Persze ugy nehez megitelni a dolog problematikussagat, ha mondjuk a Java-n kivul nem programoztal egyeb kornyezetekben. Ez az egyik oka, hogy erdemes kb. evente megtanulni legalabb alapfokon (egy kisebb projekt erejeig) egy uj nyelvet, szelesiti a latokort -- ha mondjuk senior fejleszto korodra mar irtal hasznalhato dolgokat legalabb 5-8 nyelvben, az mindenkepp hasznos. Csomo minden van, ami nem hianyzik addig, amig egyszer nem lattad -- pl. csomo Java-fejlesztot nem idegesit az, ahogy a generikusokat implementaltak a Java 5-ben, pedig egeszen elkepesztoen fajdalmas kb. minden mas implementaciohoz kepest. Ha viszont mittudomen, volt mar elotte C++ vagy C# tapasztalat, akkor legalabb tudod, hogy hogy kene mukodnie, ha rendesen meg van csinalva (es forditva is igaz, amig az ember pl. csak .Netet latott, addig nem ertekeli, hogy pl. a build rendszerek mennyivel jobbak JVM platformon; vagy a temahoz kapcsolodva: a mai napig ledobbenek, hogy 1000-1500 sornyi Java kod funkcionalitasa Scala-ban vagy Clojure-ben 50 sor, es vilagos, mint a nap).Tenyleg erdemes a lenti rovid eloadast (is) megnezni, meg esetleg megcsinalni az Odersky-fele (SZUPER) Scala-kurzust:
https://www.coursera.org/course/progfunSzerk.: egyeb pelda: ha valaki meg nem futott bele abba, hogy mekkora fajdalom a single dispatch, az hazudik
-
A klasszikus objektumorientalt programozasi stilusban az alapegyseg az 'identitas', kvazi a memoriaban elfoglalt hely. A mostanaban elkezdodott, modernebbnek mondhato felfogas szerint az alapegyseg az 'ertek'. Sajnos a Java sem tamogat igazan semmi mast, csak az identitasalapu programozast, barmennyire is probaljak megoldani a problemakat mindenfele patternekkel meg frameworkokkel.
Egy olyan vilagban, ahol nem referenciakat adogatsz, hanem ertekeket, hirtelen (majdnem) megoldodnak az olyan problemak, mint
- szinkronizacios problemak, adatkorrupcio
- (alacsonyszintu) deadlockok
- 3rd party libek kiszamithatatlan viselkedese (vajon mi tortenik a konteneremmel, ha odaadom ennek a fuggvenynek, aminek nem latok bele a forrasaba?)... satobbi. Erdemes nekiallni szerintem ennek a temanak, lesz piaca (meg egyebkent is nagyon szep dolog).
-
> Hiszen ha egy List is final, utána ugyanúgy lehetett a List-be elemeket tenni.
Jo meglatas - ami neked feltunt, az a 'constness', vagy immutabilitas koncepciojanak a (majdnem teljes) hianya a Java-ban. Az altalanos immutabilitas igazan hasznos lehetne, konkurens programozasnal (is) egy aldas, meg egyebkent is sokkal atlathatobb, bugmentesebb kodot lehet irni akkor, ha az ember ahol csak lehet, 'ertekkel' es nem 'identitassal' dolgozik.
-
#6245
jetarko
csendes tag
Aethelstone
#6238
jetarko
csendes tag
válasz
Aethelstone
#6238
üzenetére
Valahol el kell kezdeni és mivel suliba ilyet nem tanítanak, ezért első körbe az ilyen netes tutorialokat nézegettem, de azt én is leszűrtem, hogy nem az igaziak, már ha egyáltalán működnek.
Suliba belenéztünk kicsit JPA-ba, de amúgy csak SE volt.
Majd most utána akarok nézni a memory profiling-nak meg az alkalmazás szerverek konfigurálásának, mert az, hogy én localhost-ba elszórakozok egy projectel az oké, de ha ez éles project lenne, akkor gondolom számítana memória használat, skálázhatóság és még nem tudom mik.
Még fél évig suli mellett nem tudok menni melózni, ezért addig marad az itthoni tanulgatás, mert érdekel a java ee világa.És miből lenne érdemes tanulni a netes tutorialok helyett? Álljak neki olvasni az igencsak hosszú hibernate és spring doksit?
Ha már szóba jöttek a design pattern-ek párat mondanátok, amiket érdemes lenne tanulgatni, használni ebben a témában?
-
#6241
floatr
veterán
Aethelstone
#6240
floatr
veterán
válasz
Aethelstone
#6240
üzenetére
Régebben én is szkeptikus voltam, de ahogy látom ahogy hígul a szakma, és kik mondják magukat java fejlesztőnek, neadjaég senior-nak, azóta úgy érzem, hogy az egyik legjobb ötlet volt a minták nyomatása.
-
#6239
floatr
veterán
Aethelstone
#6238
floatr
veterán
válasz
Aethelstone
#6238
üzenetére
És egy C/C++ fejlesztő ismerős kérdezte, hogy mi a fenéért nyomják ezeket a tervezési mintákat... hát ezért.
-
#6237
floatr
veterán
Aethelstone
#6236
floatr
veterán
válasz
Aethelstone
#6236
üzenetére
Ja, hát ez a kézimunka elég nagy marhaság a példákban, pláne hogy mindenki ebből tanulna a zinternetrül. Épp most tépem a hajam, hogy egy olyan projektbe ugrottunk be, amit olyan "szakik" készítettek elő, akik netes példákból ollózták össze a tudásukat.
-
#6235
floatr
veterán
Aethelstone
#6233
floatr
veterán
válasz
Aethelstone
#6233
üzenetére
JTA vagy sem, ha már Spring-et használ, akkor ott van a @Transactional(propagation=Propagation.SUPPORTS) vagy REQUIRED
-
floatr
veterán
A filter annyit csinál, hogy egyazon session-t fog visszaadni a request idejére. Ez akkor kellhet, ha lazy collection-öket használsz, de nem inicializálod őket a betöltéskor. Ilyenkor session hibával hanyatt esik az egész.
A tranzakció egy kicsit más, azt definiálhatsz többet is pl. annotációval a business layer-ben. Ha egy controller több business metódust használ, akkor több tranzakció is kifuthat menetközben.
(#6230) jetarko nem lassabb lesz, hanem néha feleslegesen végzi a munkát, több memóriát ehet stb. Amikor EAGER-nek definiálsz egy kapcsolatot, akkor a tulaj betöltése nem egy szimpla select lesz, hanem hozzáfűzi az összes kapcsolatot, és egy menetben tölti be az adatokat.
Amikor a size() metódust használod LAZY-vel, akkor külön SQL fut le a collection-re.Ami duplikálódást illeti, asszem itt már azért látszódik, az oka az egésznek. EAGER az összes kapcsolatod, ezért szépen sorban hozzáfűzi JOIN-nal a TEAM táblához a lekérdezésnél. 1 join esetében a TEAM duplikálódik, minden további join esetében viszont a hozzáfűzött táblák rekordjai is. Itt lehet kutya elásva. Valószínűleg több collection is duplikált adatokat fog tartalmazni emiatt az összesített SQL miatt. Amikor a példámban néztem, nekem csak egy one-to-many kapcsolatom volt, amiben a tulaj szűrve volt, a collection elemei pedig egyszer jöttek a select-ből. Ha több ilyen van, akkor a select egyszerűen ilyen hulladék eredményt ad.
Emiatt is érdemes lenne subselect-eket használni valamilyen módon. Mondom, én a filtert javaslom LAZY-vel
-
Szmeby
tag
válasz
jetarko
#6230
üzenetére
Asszem készült egy olyan service metódus (getFullInitializedById() vagy valami ilyesmi), ami id alapján lekérte az entitást (szigorúan lazy fetch minden mezőre), majd az id-val egyesével legyűjtögette a listákat is és a setterekkel beállította azokat az entitáson. Mindezt beburkolva 1 tranzakcióba.
Megjegyzem, tette mindezt azért, mert állandóan nyitott tranzakció / session nem létezett a programban, mindig csak a service metódusban nyílt, elvégezte a szükséges adatbázis műveleteket majd lezárult. Márpedig lazy fetch esetén a listák nem igazi listák csak proxy objektumok, és amint ráhív az ember gyanútlanul egy ilyenre, miközben nincs mögötte aktív session, a cucc borul, mint annak a rendje.
Persze ha neked mindig van nyitott session-öd, akkor talán nem kell vesződnöd a proxyk igazi listára cserélgetésével.De ezt ne vedd követendő példának, nagyon keveset Hibernate-eztem, és azóta csak felejtettem. Nem tartom magamat hozzáértőnek.
select team0_.id as id1_4_0_, team0_.name as name2_4_0_, team0_.points as points3_4_0_, team0_.price as price4_4_0_, races1_.resultOfTeams_id as resultOf2_4_1_, race2_.id as races_id1_3_1_, race2_.id as id1_1_2_, race2_.date as date2_1_2_, race2_.location as location3_1_2_, resultofdr3_.races_id as races_id1_1_3_, driver4_.id as resultOf2_2_3_, resultofdr3_.resultOfDrivers_ORDER as resultOf3_3_, driver4_.id as id1_0_4_, driver4_.name as name2_0_4_, driver4_.points as points3_0_4_, driver4_.price as price4_0_4_, driver4_.team_id as team_id5_0_4_, users5_.team_id as team_id2_4_5_, user6_.id as users_id1_7_5_, user6_.id as id1_5_6_, user6_.money as money2_5_6_, user6_.name as name3_5_6_, user6_.password as password4_5_6_, user6_.points as points5_5_6_, drivers7_.users_id as users_id1_5_7_, driver8_.id as drivers_2_6_7_, driver8_.id as id1_0_8_, driver8_.name as name2_0_8_, driver8_.points as points3_0_8_, driver8_.price as price4_0_8_, driver8_.team_id as team_id5_0_8_
from TEAM team0_
left outer join RACE_TEAM races1_ on team0_.id=races1_.resultOfTeams_id
left outer join RACE race2_ on races1_.races_id=race2_.id
left outer join RACE_DRIVER resultofdr3_ on race2_.id=resultofdr3_.races_id
left outer join DRIVER driver4_ on resultofdr3_.resultOfDrivers_id=driver4_.id
left outer join USER_TEAM users5_ on team0_.id=users5_.team_id
left outer join USER user6_ on users5_.users_id=user6_.id
left outer join USER_DRIVER drivers7_ on user6_.id=drivers7_.users_id
left outer join DRIVER driver8_ on drivers7_.drivers_id=driver8_.id
where team0_.id=?Ha ezt végrehajtod az adatbázison valamilyen id-val a ? helyén, akkor megnézheted a duplikátumokat. Kis elemszámú listák esetén is nagy resultset képződik ebből.
Az, hogy valami lassú, nem számít. Fontosabb, hogy optimális legyen. Ha teszemazt azonnal szükség van x, y, és z táblákból (összetartozó) adatokra, akkor gyorsabb előállítani azokat egy lekérdezéssel. De ha első körben csak az x-re van szükséged, és fontos a reszponzivitás, akkor y és z ráér később, ajánlott a lazy-re állítani. Az igényektől függ, hogy mi a jó megoldás.
(#6231) jetarko
Szerintem nem. Eagerben minden táblát join-ol és egy lekérdezéssel letudja az adatok elővételét. Lazyben csak a fő entitást veszi elő, majd a size() metódushíváskor aktiválja a proxyt, ami előállít egy újabb selectet, ami a listát tölti fel értelmes adattal. Tehát utóbbi esetben több független lekérdezés pattan. -
jetarko
csendes tag
Töröltem az EAGER-t, majd módosítottam a fv-t és így jól működik.
Az oké, hogy az EAGER lassabbá teszi az alkalmazást, de ha ezeknek a listáknak a mérete kicsi, akkor gondolom nem számít. MySQL-t használok(#6228) Szmeby: Többszöröződés, jelen esetbe 2 helyett 8 lett a lista mérete.
És ezt a külön Select-et hol kéne megvalósítani? Csináljak olyat, hogy a Driver táblából lekérem azokat a sorokat amiknél a team_id megfelel annak amit keresek?Bekapcsoltam a show_sql-t és ezt a förmedvény-t dobja. Az utolsó sor csak akkor van ha a fv-be beírom a t.getDrivers().size()-t.
-
Szmeby
tag
válasz
jetarko
#6225
üzenetére
Duplázódás vagy többszöröződés van?
Most hogy láttam a kódod, előjöttek a régi emlékeim.
Nálam többszöröződés jött elő, az adatszerkezet kicsit más volt, de a lényeg ugyanaz: egy entitásban több (egymástól független) lista eager fetch-csel.A problémám az volt, hogy a listák ugyan kis elemszámúak voltak, de többnyire nem 1 elemet tartalmaztak, hanem 2-6 körül. Ami azt eredményezte, hogy a Hibernate a háttérben megcsinálta ezek Descartes-szorzatát, tehát egy 3 elemű lista megtriplázta a másik lista elemeit. (És a Hibernate szerint ez így normális.)
Esetleg érdemes lehet bekapcsolnod a show_sql kapcsolót, hogy megnézhesd, milyen sql lekérdezést gyárt, és azt külön elpattintva milyen resultsetet kapsz. Ne számíts arra, hogy a Hibernate a háttérben majd megszűri neked a duplikátumokat.
Már jó rég volt, de ha jól emlékszem, végül az lett a megoldás, hogy a listákat külön-külön select töltötte fel. A design nem engedte meg, hogy Settel bohóckodjak.
-
sunnysys
tag
válasz
Aethelstone
#6181
üzenetére
Köszönöm!
Akkor keresek ilyen irodalmat, mert enélkül csak a saját logikámra támaszkodhatok, ami valószínűleg egy idő után már korlátoltan lesz csak elég.
"Gyorsan haladni? Alapvető szabály, hogy akkor lehet igazán hatékonyan megtanulni programozni, ha van értelmes feladat. Nem telefonregiszter és nem DVD kölcsönző nyilvántartás. Viszont komolyabb, életszagú, szopós feladatok csak éles munkahelyi környezetben szoktak adódni
"Na, de honnan tudhatom, hogy mi az értelmes feladat? Teljesen kezdő vagyok, amíg tanárt nem találok, csak netről, könyvekből tájékozódhatok. Munkahelyi környezet pedig egy jó ideig nem áll majd rendelkezésre, gondolom.
-
floatr
veterán
válasz
jetarko
#6225
üzenetére
Pedig nekem is van hasonló mapping pár, és nem látok benne hibát. Kipróbáltam a saját alkalmazásban átírni a collection-t EAGER-re, de akkor sem csinálta ezt. Azt még esetleg megpróbálhatnád, hogy egy teszt erejéig kiszeded az EAGER-t, és a korábban bemásolt kódrészletet kibővíted így:
public Team getTeamById(int id) {
Session session = this.sessionFactory.getCurrentSession();
Team t = (Team) session.get(Team.class, new Integer(id));
// ha lazy collection, akkor így betölti az elemeit egy második query-ben
t.getDrivers().size();
return t;
}Még esetleg azt tudom elképzelni, hogy dialect-függő a dolog. Én eddig mssql, postres és derby adatbázisokkal használtam, de csak elcseszett join-ok esetében találkoztam hasonlóval.
Annyit még érdemes megfontolni, hogy az EAGER típusú kapcsolatok nagyon oda tudnak vágni az alkalmazásnak, ezért is alapértelmezett a LAZY. Én mindenhol ezt használom, és inkább egy OpenSessionInViewFilter-t teszek a web.xml-be. Oda akkor viszont már kelleni fog tranzakció is meg egyebek.
-
#6222
jetarko
csendes tag
Aethelstone
#6190
jetarko
csendes tag
válasz
Aethelstone
#6190
üzenetére
Köszi a választ, örülök, hogy nem én vagyok ilyen béna, de a google skillemen van mit javítani mert hasonló dolgokat írtam be, de még se találtam stackoverflow-os kérdést erre.
Most magamnak írogatok csak programokat ezért az adatbázis mérete nyilván kicsi, de ha van 1millio rekord akkor az adatok lekérése Set-tel sokkal lassabb mint bármelyik List a beszúrási idő miatt. Vagy az elején teljesen felesleges hatékonysági problémákon gondolkodnom?
Amúgy netes tutorial alapján csináltam dao és service-ket és ahol konkrétan lekérem az így néz ki:
public Team getTeamById(int id) {
Session session = this.sessionFactory.getCurrentSession();
Team t = (Team) session.get(Team.class, new Integer(id));
return t;
}A team entitásban meg ugye csak simán van egy Set<Driver> és aztmondom, hogy getTeamById(1).getDrivers() szóval nem látom hova rakhatnám a distinct-et ezért marad Set.
Vagy dobjam a dao és service osztályt és ilyen namedQuery-ket írjak? -
#6221
floatr
veterán
Aethelstone
#6194
floatr
veterán
válasz
Aethelstone
#6194
üzenetére
Mondjuk sok támpontom nem volt, csak a kolléga kódja, ő meg égert használt annotációban
-
#6220
WonderCSabo
félisten
Aethelstone
#6219
WonderCSabo
félisten
válasz
Aethelstone
#6219
üzenetére
OK, valóban kezdünk eltérni a témától, sorry.
-
#6219
Aethelstone
addikt
WonderCSabo
#6218
Aethelstone
addikt
válasz
WonderCSabo
#6218
üzenetére
A DISTINCT-nek akkor van szerintem értelme, hogy a a lekérdezésben egy konkrét mezőt akarsz visszakapni, az idézett problémakörben mondjuk egy nevet, de csak egyszer
Órákat, napokat lehetne beszélni a témáról
-
#6218
WonderCSabo
félisten
Aethelstone
#6217
WonderCSabo
félisten
válasz
Aethelstone
#6217
üzenetére
OK, azért szerintem jogos a duplikált sor lehetősége, különben a DISTINCT operátor értelmét vesztené, csak ezt akartam mondani.
Az viszont lehet, hogy így objektum-relációs leképezésen nem nagyon lehet használni, ebben valszeg igazad van, elnézést. -
#6217
Aethelstone
addikt
WonderCSabo
#6216
Aethelstone
addikt
válasz
WonderCSabo
#6216
üzenetére
Nos, úgy látom, hogy kezdenek itt keveredni a dolgok. Nyilván valamiféle ID-ben el kell térniük, különben alapvető relációs adatbázis kezelési elvek sérülnek. Ha van egy Szemely táblám, amiben két személy csak a személyi számban tér el, akkor a Hibernate/MySQL szempontjából az két eltérő entitásként lesz "objektumizálva", függetlenül attól, hogy a többi metaadat ugyanolyan koppra. A korábban tárgyalt probléma eddig terjed.
Hogy a Java kódban a személyi számot az equals() metódusnál nem veszem figyelembe, az működhet, de ez ebben az esetben a konkrét adatbázis logika lábbal tiprása és semmi köze az ORM implementációhoz.
Hivatalos doksi nincs erről, legalábbis én nem találtam, de az egyik kolléga korábban említette, hogy a hivatalos Hibernate fórum milyen színvonalú. Ott a Hibernate fejlesztők workaroundként javasolják a DISTINCT és a Set használatát, ami kvázi hivatalos álláspont. Ráadásul mi a 3.x-es Hibernatet használjuk, aminél bőven van újabb is, de különféle okok miatt nem tudunk/akarunk egyelőre upgradeolni.
Ettől függetlenül simán lehet, hogy van ennek a problémának rendes megoldása, de ezt én eleddig nem találtam meg, főleg azért nem, mert éppen ma futottam bele ebbe én is és még nem volt időm bővebben kivesézni
-
#6216
WonderCSabo
félisten
Aethelstone
#6214
WonderCSabo
félisten
válasz
Aethelstone
#6214
üzenetére
Nyilván az ID-k eltérhetnek, de azt a java kódban az equals metódus-nak nem kell feltétlenül figyelembe vennie, és akkor máris egyenlő két egyed.
Persze az ilyen dolog is még ki fog bukni normalizáláskor, de egyrészt nem kell minden adatbázisnak x. normálformában lennie, másrészt ez az egyszerű példa is mutatja, hogy nagyon sántít ez a dolog.Én OrmLite-ot használok ORM-ként Android-on, az sosem csinált ilyet. Most rákerestem erre a Hibernate OneToMany duplicates problémára, és mindenhol azt olvastam, hogy rosszul volt használva a cucc.
Én elhiszem hogy ez így működik, mivel nem használtam még Hibernate-et (se semmilyen JPA implementációt), de akkor is nagyon furcsának tartom ezt. Ha esetleg erre van doksitok, ami leírja hogy ez az elvárt működés, az hasznos lenne.
-
#6215
Szmeby
tag
Aethelstone
#6213
Szmeby
tag
válasz
Aethelstone
#6213
üzenetére
És ezen álláspontjukat nagyon arrogánsan képesek védeni is. Borzasztó lekezelően viselkednek a segítséget kérőkkel, cserébe viszont semmi konstruktívval nem tudnak szolgálni. Persze én vagyok a hülye, hogy a Hibernate fórumon kérek segítséget a Hibernate-tel kapcsolatban.
-
#6214
Aethelstone
addikt
Aethelstone
#6213
Aethelstone
addikt
válasz
Aethelstone
#6213
üzenetére
Lejárt a módosítás. Ha nem unique sorok vannak, akkor ott a normalizálás sérül....azt meg a kukába kell vetni ilyenkor.
-
#6213
Aethelstone
addikt
WonderCSabo
#6212
Aethelstone
addikt
válasz
WonderCSabo
#6212
üzenetére
Akkor használsz List-et, ami a szükséges és a szükségtelen duplikációkat is kezeli. Aztán majd "kézzel" kiszeded. Semelyik ORM nem tud 100%-os lenni.
Másrészről ez a hivatalos Hibernate álláspont, tehát szándékosan ilyen ez látszólag. A Hibernate sokszor nem úgy viselkedik, mint a tiszta JDBC. Ezekkel együtt kell élni.
Harmarészt miért lennének nem unique sorok? Azt hibás tervezés eredménye lehet max.
-
#6212
WonderCSabo
félisten
WonderCSabo
félisten
Olvasom itt a fórumot erről a Hibarnete-es esetről. Én nem használom a Hibernate-et, de józan paraszti ésszel nézve és némi adatbázis használattal a hátam mögött, kizártnak tartom, hogy ez normális viselkedés. A Set és DISTINCT inkább csak a hiba elfedésének tűnik.
Pl. mi van akkor, ha nem uniqe sorok vannak a db-ben (nem jellemző, de akár lehetne). Akkor hogyan oldod meg, hogy ne legyenek felesleges duplikációk, mert a Set és DISTINCT az igazi duplikációkat kinyírja. -
#6211
Aethelstone
addikt
jetarko
#6179
-
#6209
Mukorka
addikt
Aethelstone
#6208
Mukorka
addikt
válasz
Aethelstone
#6208
üzenetére
Akarom mondani singleton
-
#6207
Mukorka
addikt
Aethelstone
#6206
Mukorka
addikt
válasz
Aethelstone
#6206
üzenetére
Ha már úgy is van egy külön nem lazy metódusod erre akkor az jelzi hogy néha előfordul hogy kell minden. Sztem belefér, jobb mint fölöslegesen felhozni minden adatot és aztán hagyni hogy a hibernate fölöslegesen dolgozzon rajta. Igen, ízlés dolga
Kell írni sebesség teszteket rá és el lehet pöcsölni még vele egy csomót
(#6208) Aethelstone: Nem tudom, ritka jól sikerült objektum vagyok =)
-
#6205
Mukorka
addikt
Aethelstone
#6204
Mukorka
addikt
válasz
Aethelstone
#6204
üzenetére
Átírtam a választ
-
#6202
Mukorka
addikt
Aethelstone
#6201
Mukorka
addikt
válasz
Aethelstone
#6201
üzenetére
Akkor inkább a distinct, a set nem szép.
Igazából itt az a baj hogy egyszerre kéred le egy selectben. Esetleg át lehet írni hogy egy másik select hozza le a kapcsolatokat vagy ahogy nálunk sokan tolják (nem is szép) meghívni a size()-t, amit persze ti kikapcsolattatok azzal az extra annotációval.
)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
"
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Újszeru GIGABYTE G5 - 15.6" FullHD 144Hz - i7-13620H - 48GB - 1TB - RTX 4050 - Win11 - 1,5 év gari
- Eladó garanciás,új állapotu projektorom kihasználatlanság miatt!
- Acer Nitro V ANV15 - 15.6"FHD IPS 144Hz - i5-13420H - 16GB - 512GB - Win11 - RTX 3050 - 2,5 év gari
- GIGABYTE GeForce RTX 4060 EAGLE OC 8G (GV-N4060EAGLE OC-8GD
- TP-Link Archer AX73 AX5400 Router
- AKCIÓ! Apple Macbook Pro 16" 2019 i9 9980HK 64GB 500GB Radeon Pro 5500M hibátlan működéssel
- Garmin Fenix 8 Amoled 51mm Sapphire Carbon Gray DLC - Használt, karcmentes
- HP Probook 650 G4 15,6 i5-8350u 8. gen. GYÁRI MAGYAR VILÁGÍTÓ BILL!!!
- ÚJ Lenovo Yoga Slim 7 - 14.5" 3K OLED Érintő 90Hz - Snapdragon X Elite - 32GB - 1TB - 2,5+év gari
- IKEA Format lámpák eladóak (Egyben kedvezménnyel vihető!)
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged