- Milyen videókártyát?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Fejhallgató erősítő és DAC topik
- A Linux megnégyszerezte magát a Steamen — a Microsoft ismét ígérget
- AMD vs. INTEL vs. NVIDIA
- Először kombinálja a Full HD-t az 1000 Hz-cel egy monitor
- AMD Navi Radeon™ RX 9xxx sorozat
- Projektor topic
- Speciális kiadású AMD-s alaplapot villantott az ASUS a 20 éves ROG-jubileumra
- Apple MacBook
Új hozzászólás Aktív témák
-
-
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.
-
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ő.
-
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ő.
Ha mindenképp külön akarod venni, akkor miért nem csak egy linket laksz az első oldalra, ami átdob a másikra ahol a login form várja a usert? Sokkal tisztább
-
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ő.
-
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...
Hogy érted azt, hogy indítasz egy másikat?
-
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...
-
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...
-
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
) -
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
) -
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
) -
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.Ja, értem már.
-
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.Én ismerem, szoktam játszani, bár eddig csak JS vonalon, mostantól lehet a Java is az esti elfoglaltság része lesz
-
Csak az utolsó mondatra.: Van benne igazság...de kicsit úgy írod mintha ezekkel nem lehetne, vagy "alantasabb" lenne... Komolyan kérdezem mi az más a véleményed szerint?
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. -
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.
-
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. -
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.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. -
emvy
félisten
Igen, ha immutable akkor menni fog - efelett elsiklottam. Mondjuk engem megőrjítene, ha a listám immutable lenne, de mindegy.
> 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)). -
WonderCSabo
félisten
-
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. -
Aethelstone
addikt
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.
-
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.
-
emvy
félisten
Nos. Alapvetően igazad van, de a fejlesztőtársadalom túlnyomó része nem a "szakma krémje", nem ismer készség szinten 3-4 programnyelvet, 1-2 nyelvből próbál megélni, életben maradni és nem érdeklik ezek a magas dolgok. Ha érted, hogy mire gondolok.....
-
emvy
félisten
Számítottam erre válaszra.
Ha a csak előlépsz egyet a head-től, akkor a második listával szépen felül lehet írni az első lista 2. elemétől az összeset.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.
-
WonderCSabo
félisten
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.
Számítottam erre válaszra.
Ha a csak előlépsz egyet a head-től, akkor a második listával szépen felül lehet írni az első lista 2. elemétől az összeset. -
emvy
félisten
Persze, ez elemeket magukat nem kell lemásolni, viszont bele kell szúrni az összes elemet átadásnál (vagy nem?). Alapvetően Javában is nagyon sokszor alkalmazzuk ezt (defensive copy).
-
WonderCSabo
félisten
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
Ez tényleg már csak kekeckedés, de nem i++, hanem ++i by default a for ciklusban
-
Aethelstone
addikt
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.
Ez tényleg már csak kekeckedés, de nem i++, hanem ++i by default a for ciklusban
-
Aethelstone
addikt
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
-
emvy
félisten
Én mi van a performanciával? C++ -ban és sok máshol az érték szerinti paraméterátadásnál az egész cucc lemásolódik (copy constructor-al). A modernebbnek mondható felfogás esetén hogy oldják meg?
-
WonderCSabo
félisten
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).
-
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.
-
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
-
emvy
félisten
Nos, nekem az a véleményem, hogy az általad felsoroltak csak elméleti problémák.
Ráadásul a patternek és frameworkok pontosan azt segítik elő, hogy ezek az elméleti problémák elméletiek is maradjanak.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
-
Aethelstone
addikt
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.
magyarul?
-
Aethelstone
addikt
-
jetarko
csendes tag
A mykong-féle nagytudásúak bemutatnak pár mórickát és az alulképzettek azt hiszik, hogy ez a frankó
Volt nekem is egy projektem, gyönyörűen meghúzták a DAO rétegben a tranzakciós határokat Persze EE környezetben -
Aethelstone
addikt
-
-
floatr
veterán
Pssszt! A C/C++ fejlesztők a teremtés koronái
Egyébként Java fejlesztők sem mind értik, hogy mi a rák az a dizájn pattern.. -
Aethelstone
addikt
-
floatr
veterán
A mykong-féle nagytudásúak bemutatnak pár mórickát és az alulképzettek azt hiszik, hogy ez a frankó
Volt nekem is egy projektem, gyönyörűen meghúzták a DAO rétegben a tranzakciós határokat Persze EE környezetben -
Aethelstone
addikt
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.
A mykong-féle nagytudásúak bemutatnak pár mórickát és az alulképzettek azt hiszik, hogy ez a frankó
Volt nekem is egy projektem, gyönyörűen meghúzták a DAO rétegben a tranzakciós határokat Persze EE környezetben -
floatr
veterán
Jah, sokféle JÓ megoldás van. A kézzel nyitom-zárom a tranzakciókat nem tartozik feltétlenük ezek közé.
szerk:
Természetesen menedzselt környezetben.
-
Aethelstone
addikt
-
floatr
veterán
A varázsszó a JTA. Nem kell pöcsölni a tranzakciókkal manuálisan.
-
Aethelstone
addikt
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. -
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.
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. -
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.
-
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.
-
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.
-
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
Tehát az alapvető programozási szemléletet (vagy hogy is nevezzem) is meg kellene tanulnom.
Ezt hivatalosan tervezési mintának vagy design patternnek nevezik. Rengeteg ilyen témájú cikk van a neten, azokból lehet kiválóan tájékozódni. Egyébként ez a számológépes dolog szerintem így rendben van. Nem hiszem, hogy egy ilyen kvázi egyszerű feladatot nagyon el kellene bonyolítani. Persze lehet. Csinálhatsz JTextFieldből származtatott saját TextField-et, ami már elvégzi alapból a parseolást, de nem biztos, hogy a befektetett munka megéri. Ha viszont tanulni akarsz, akkor érdemes lehet belevágni
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
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.
-
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? -
jetarko
csendes tag
Eh, pont most ütköztem bele egy hasonló problémába
Duplikált eredmény. Egy DISTINCT megoldotta, de nekem még nem tetszik így.szerk:
Pontosabban NamedQuery-t használunk. Az OneToMany alapból Lazy, de Eagerhez írtunk egy FETCH JOIN-os queryt, ami a rohadt életbe duplikál. Egy SELECT DISTINCT megoldotta. Nézegetem a netet, hogy mi lenne a szebb megoldása....
-
floatr
veterán
Azért, mert az annotációk szerint LAZY, viszont ha kell minden, akkor azt EAGER-ben kell ugyi. A sima JOIN meg ugyancsak LAZY, ahogy én tudom. Attól lesz EAGER , hogy kap egy FETCH-et is.
Forráskóddal:
@NamedQuery(name = "correlationRuleSet.eager", query = "select distinct crs from CorrelationRuleSet crs left join fetch crs.correlationRules")
})
public class CorrelationRuleSet extends AbstractAclEntity {
private static final long serialVersionUID = -9143224663183869606L;
@Column(name = "name", length = 256)
private String name;
@OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY, mappedBy = "correlationRuleSet")
@Cascade(org.hibernate.annotations.CascadeType.DELETE_ORPHAN)
@LazyCollection(LazyCollectionOption.EXTRA)
private List<CorrelationRule> correlationRules = new LinkedList<CorrelationRule>(); -
WonderCSabo
félisten
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
OK, valóban kezdünk eltérni a témától, sorry.
-
Aethelstone
addikt
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.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
-
WonderCSabo
félisten
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
-
Aethelstone
addikt
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.
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
-
WonderCSabo
félisten
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.
-
Szmeby
tag
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.
É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.
-
Aethelstone
addikt
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.
-
Aethelstone
addikt
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. -
WonderCSabo
félisten
-
Aethelstone
addikt
Sziasztok
Hibernate-ben van egy onetomany kapcsolatom:
@OneToMany(mappedBy="team", fetch = FetchType.EAGER)
private List<Driver> drivers;és a párja:
@ManyToOne
@JoinColumn(name = "team_id")
private Team team;Spring MVC-t használok és megírtam dao-kat,service-ket ha ez számít. xml-ben semmi mappingolást nem állítok.
Amikor lekérem az egyik csapathoz tartozó pilótákat, akkor vmiért többször teszi bele a listába ugyanazokat az elemeket. Van amikor A,B,A,B,A,B de van h A,A,B,B,A,A,B,B sorrendben kerül a listába. Ha átírom set-re megoldódik a probléma, de gondolom listánál se ez lenne a normális működés. Vmi tipp?Szóval, hogy az eredeti felvetésre is válaszoljunk.
Abszolúte normális, amit tapasztalsz, Hibernate "jellegzetesség". A Set vagy a DISTINCT használata megoldja a "problémát"
(Attól függően, hogy miként kéred le az adatokat) -
Aethelstone
addikt
-
Mukorka
addikt
A fene tudja. Azt kellene lemérni, hogy a DISTINCT drágább-e vagy a Hibernate processzor és memóriaideje
szerk: Egy rugóra jár az agyunk
Nem vagy Te véletlenül én? Akarom mondani singleton
-
Aethelstone
addikt
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 =)
A fene tudja. Azt kellene lemérni, hogy a DISTINCT drágább-e vagy a Hibernate processzor és memóriaideje
szerk: Egy rugóra jár az agyunk
Nem vagy Te véletlenül én? -
Mukorka
addikt
Persze, de ez már ízlés dolga. Amit meg lehet tenni 1 SELECT-ben, arra miért írjunk 2 SELECT-et?
szerk:
Ráadásul teljesítmény-igényes alkalmazásnál nem is biztos, hogy jó a 2 SELECT.
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 =)
-
Aethelstone
addikt
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.
Persze, de ez már ízlés dolga. Amit meg lehet tenni 1 SELECT-ben, arra miért írjunk 2 SELECT-et?
szerk:
Ráadásul teljesítmény-igényes alkalmazásnál nem is biztos, hogy jó a 2 SELECT.
-
Mukorka
addikt
Semmivel nem lennénk előrébb. Nem arról van szó, hogy van NULL-os eredmény.
Átírtam a választ
-
Aethelstone
addikt
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.
-
Aethelstone
addikt
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.
-
Mukorka
addikt
Az idézett linket megnézted?
szerk: Akkor igen
Persze, jogos. Van is rá megoldás DISTINCT vagy Set. -
Aethelstone
addikt
)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Milyen videókártyát?
- Vicces képek
- Luck Dragon: Asszociációs játék. :)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Kerékpárosok, bringások ide!
- Huawei Watch Fit 5 Pro - jó forma
- Formula-1
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- exHWSW - Értünk mindenhez IS
- Forza sorozat (Horizon/Motorsport)
- További aktív témák...
- 24 magos AMD Threadripper alapú munkára kiváló félgép, 128GB RAM-mal
- HP ZBook Fury 15 G7 i7-10850H 32GB 512GB SSD Quadro T2000 4GB FHD HUN bill, szép állapotban eladó
- Eladó MacBook Pro 16,1 2019 CTO
- új 0 km es garanciás lenovo loq rtx 5050 8gb
- Eladó teljesen újszerű karcmentes Samsung Galaxy Watch Ultra
- ÚJ Lenovo LOQ Intel Core i7-13650HX, 32GB, 1TB, RTX 5060(8GB), FHD 144Hz
- Xiaomi Redmi Note 12 128GB, Kártyafüggetlen, 1 Év Garanciával
- Crucial 2x8GB DDR5 Notebook RAM
- AKCIÓ! Apple Macbook Air 15 2025 M4 24GB RAM 512GB SSD notebook garanciával hibátlan működéssel
- AKCIÓ! LENOVO ThinkPad P15s Gen2 munkaállomás - i7 1165G7 16GB DDR4 512GB SSD Quadro T500 4GB W
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest