- Samsung Galaxy S23 Ultra - non plus ultra
- Google Pixel topik
- Milyen okostelefont vegyek?
- VoLTE/VoWiFi
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Mi nincs, grafén akku van: itt a Xiaomi 11T és 11T Pro
- Yettel topik
- Magisk
- További kavarás a Pixel 10-ek körül
- A lapkakészlet és az akku különbözteti meg a Motorola Edge 60 és Edge 60 Pro-t
Új hozzászólás Aktív témák
-
#8067
Aethelstone
addikt
jetarko
#8063
-
fatal`
titán
-
Ursache
senior tag
válasz
jetarko
#7307
üzenetére
Alacsony a ponthatár, persze, mert nem a 480 pontos végigmagolomazéreccségit típusú emberek jönnek ide, akik sírnak, hogy alig van hely, meg fizetős meg etc, persze, mert a sok kamu szak most a divat, boldog-boldogtalan odamegy. Aztán hallom vissza az olyan történeteket, hogy pénzügyre jár egy csaj, és hogy neki pont 100 embert kell megkérdeznie, hogy %-osan kijöjjön az eredménye.
MSc-t csak külföldre ajánlják ezen a szakterületen.
-
Ursache
senior tag
válasz
jetarko
#7305
üzenetére
A B tényleg nem a legjobb választás (szerintem sem). Ugyanakkor azért nem csak ezeket tanuljuk, és tényleg piszok sok a matek. De kell is, adott esetben! Ma (tegnap) is mesterséges neurális hálók esetében előjött a parciális deriválás. Hibafüggvények minimalizálása, regresszió, szélsőértékek... Nem véletlenül van modalg is, nagyon helyesen. El lehet menni OKJ-re is, lehet ott többet vesznek progból, ami tényleg prog, de nem ennyire mélyen. Ha ezt a szakot elvégzed, utána nincs gondod azzal, hogy hova menj, mindent meg tudsz ezek után tanulni, szóval full felesleges még 50 tárgyat hozzáadni a képzéshez. Pedig akkor is lehetne mondani, hogy de ez meg ez nem volt. Szóval nem elvárni kell, hanem betanítani, megtanítani...
Amúgy meg az egész google, csak jól kell tudni használni
-
#7109
Oppenheimer
nagyúr
jetarko
#7103
Oppenheimer
nagyúr
válasz
jetarko
#7103
üzenetére
(#7103) jetarko:
Itt szerintem fel kell sorolni azokat a packageket amikben @componentekre hivatkozol. Pl dao(repo) service csomagok is.Felsorolhatom, de nem kéne neki rekurzívan bejárni a packageket?
A spring xml-ben emf-t adtál meg, a repoban meg em-re hivatkozol.
Tutorialokból raktam össze. A célom az lenne, hogy @PersistenceContext annotációval be tudjak injektálni EntityManagert, és azt használni. Egyébként itt ezt írja: Spring injects @PersistenceContext into Spring components on its own. In order to do so, applications need to be have access to an EntityManagerFactory bean. Gondolom ezért tettek a tutorialban a spring-servlet.xml-be LocalContainerEntityManagerFactoryBean-t.
Ha ehhez a funkcionalitáshoz, amit írtam, valami más kéne a spring-servlet.xml-be, nyugodtan szóljatok.Az xml fájlokban miért van annyi kommentezés?
Azok olyan dolgok amik most nem kellenek, de később fognak. Először működjenek legalább az alapok.
(#7104) Lortech:
Beírtam a persistence.xml-be az alábbi sort az alapján amit floatr linkelt:
<jta-data-source>java:/DefaultDS</jta-data-source>de deployment közben továbbra is error van:
13:57:38,405 INFO [org.jboss.as.server] (ServerService Thread Pool -- 28) JBAS018559: Deployed "MovieTimeProject.war" (runtime-name : "MovieTimeProject.war")
(#7105) floatr:
Ahogy fent is írtam, kipróbáltam, hogy beállítom a jta-data-source-ot, de nem jó. Később szeretném ha az adatbázis 2db clusterezett MySQL instance lenne, köztük egy load balancerrel, és ehhez gondolom nem elég jó a RESOURCE_LOCAL transaction-type. Egyébként Wildfly 8.2-t akarok használni, nem Tomcatet.
Azt mondod, ha kidobnám a persistence.xml-t a kukába, és helyette az általad adott kóddal configolok a spring-servlet.xml-ben, akkor működőképes lesz a cucc? Ha később JTA tranzakciókra kell átállnom, akkor is megoldható lesz így?
-
-
Szmeby
tag
válasz
jetarko
#6862
üzenetére
A magam részéről feleslegesnek tartom ennyire túlbonyolítani a dolgot. Ha statikus szövegről van szó, akkor annak a pártján vagyok, hogy tároljuk property fájlban, nyelvenként külön-külön:
messages_hu_HU.properties
messages_en_US.properties
stb...
Egy új nyelv bevezetése pofonegyszerű... persze ehhez matatni kell a fájlrendszeren.Amennyiben vannak olyan szövegek, amelyek gyakran változnak, akkor azok lehetnek adatbázisban (akár in-memory db, akár ennek rendszeres backup-jával). Igazából attól függ, hogy mi a célja, mire használod a szövegeket, mennyire érzékeny adatok ezek, stb.
Azzal, hogy két helyen tárolod a cuccokat, magadra vetted ezek szinkronban tartásának terhét. Ha ez az igény, akkor nincs mit tenni. Gondoltál a teljesítmény problémákra is, csinálsz hozzá pár komponens tesztet, ezeket akár egy CI rendszerben, akár időnként kézzel megfuttatod, és nincs vele teendő. Legfeljebb majd később átírod, a szoftver úgyis mindig fejlődik.
Sosincs jó megoldás, mindig a körülményektől, a felhasználási módtól függ. Mindig kell kompromisszumokat kötni, de ha már ezt teszem, igyekszem úgy, hogy a lehető legegyszerűbb maradjon a végeredmény. Csak ezt tudom tanácsolni neked is. -
floatr
veterán
válasz
jetarko
#6859
üzenetére
Sajnos a szabadidőm érdeklődés hiányában egy ideje elmaradt, így nem tudok írni. Ha most sikerülne megoldani, hogy háromfelé osztódjak, akkor sem lenne elég, és ráadásul össze is vesznék magammal úgy, hogy egy ideig nem beszélnénk egymással
(#6858) Aethelstone naja, volt hogy dBase-ben ment az "ügyviteli" alkalmazás. Abban az időben a réteg a nikotin volt a billentyűzeten, amit kézhez kaptam.
-
moriak
tag
válasz
jetarko
#6842
üzenetére
Csak addig fogod használni az ORM-et amíg nem feltétlenül 'móricka' alkalmazásokat írsz. Reportokhoz igen is szükség van SQL-re. (már ha relációsban gondolkozunk) Nem kell félni tőle, meg kell tanulni szépen használni és könnyebb lesz a Hibernate használata is. Hibernate mellett van még a jOOQ is. Kicsit másabb a működés, de nem feltétlenül rosszabb.
Sebességet pedig 'alacsonyabb' szinten kezd el nézni. Tessék szépen a [Hikari]-t alkalmazni!!!
Amúgy kérdésedre viszont pofon egyszerű a válasz: perzisztens réteg ahogy a kolléga belinkelte. -
Szmeby
tag
válasz
jetarko
#6843
üzenetére
"A másik mód az lenne, hogy db-ben tárolok minden token és értéket..."
Ismerek olyan rendszert, ahol adatbázisban tárolják az üziket. Megvan az előnye és a hátránya, ahogy a property fájlnak is. Megjegyzem, ott nem a Properties osztályt használják erre, hanem van rá egy egyedi megoldás.Én a magam részéről a property fájlt favorizálom, mert nem látom azt az üzleti esetet, hogy ezeknek az üzeneteknek futásidőben változniuk kéne. Van egy programod, támogat 30 különböző nyelvet. Az jó esetben 30 property fájl, csókolom.
Ha adatbázisban lenne, akkor tuti készítenél hozzá valamit, amivel menet közben szerkeszteni is lehet. Az 30 db textarea. Ilyenkor történik az, hogy "ó, csak a magyar/angol nyelvűt írom át, a többi nem érdekes". És elszabadul a pokol.
Vagy pl. hogyan tervezed kiírni a "Nincs adatbázis kapcsolat" hibaüzit, ha azt adatbázisban tárolod?
Jó, persze a kivételeket bele lehet tolni a kódba, vagy property-be...Természetesen lehet olyan szöveg, ami gyakran változik, annak valóban nem property fájlban a helye, de a labelek, hibaüzik, stb. szerintem nem ilyenek.
-
#6833
Aethelstone
addikt
jetarko
#6831
Aethelstone
addikt
válasz
jetarko
#6831
üzenetére
Nem teljesen értem, de a lazy-nek nem pont az lenne az értelme, hogy csak azt tölti be, amire szükség van éppen? Ha nem hivatkozol arra a Collectionra, akkor nem töltődik be, ha meg igen, akkor behúzza. Persze, nyilván nem szabad detacholni, de ez már egy másik kérdés.
-
floatr
veterán
válasz
jetarko
#6831
üzenetére
OpenSessionInViewFilter?
Már látom a tiltakozó kezeket, mert vannak rá elméletek, hogy ez miért nem tudományos, de nálunk majdnem mindegyik projektben ez van, vagy az EntityManager-es párja.
Sokat próbálkoztunk olyan paraméterekkel, ahol megadod, hogy melyik collection-t kéne szintén betölteni a dao-ban, de aztán mindig belefutottunk olyan esetekbe, ahol nem lehetett előre tudni, hogy melyikre lesz szükség, és melyikre nem, aztán betöltöttük mindegyiket - elég tudományos ez is.
-
bucsupeti
senior tag
válasz
jetarko
#6819
üzenetére
vágj bele, nem fogod megbánni, csak adj egy kis kifutást a dolognak, mielőtt megállapításokat teszel. A lányom 16 éves. 13 éves korában a netbookjára feltettem egy ubuntut. azóta nem hajlandó megválni tőle és teljes megelêgedéssel használja a mindennapi dolgaira (tanulás, kapcsolattartás, prezentációkészítés, dokumentumszerkesztês stb)
Ja és olyan problémákat hogy belassul, vírusos stb... elfelejthetsz...
-
Pimpő
tag
válasz
jetarko
#6819
üzenetére
A Linuxban jóval több lehetőség van mint a Windowsokban. Az alap dolgokban, mint process ütemezés, memória management, I/O is jól odaver a Windowsnak. Tisztességesen scriptelhető, parancssorból is jól használható. A szoftverek installálása, törlése, kultúráltan, csomagkezelővel történik.
Csak akkor vágj bele, ha van türelmed hozzá. A kezdeti lépések nehezek lehetnek, mert a Windows-os gányolás linuxon általában nem működik. Más szemlélet kell hozzá. Sokat kell kezdetekben guglizni, kérdezni, kisérletezni.
Nekem a kedvenc disztróm a Fedora, szerintem annak a legjobb a csomagkezelője (rpm, yum). Az Ubuntu viszont jobban támogatot (két gépemen is az van), több mindenen elfut.
Linuxnál még az is szívás lehet, hogy gyakran újjítanak, cserélgetnek komponenseket, technológiákat, amikkel ugyanazokat a dolgokat lehet megcsinálni, csak másképp. Ez további tanulást és utánnajárást igényel és sokszor akkor amikor az embernek marhára nincs kedve és ideje foglalkozni vele.
Linuxon nagyobb a szabadság. Pl. az ablakezelőt is megválaszthatod. A fő disztrók alapból vmi trendi ablakkezelővel érkeznek (Unity, gnome-3). Azonban ezeknek más a filozófiájuk, mint a megszokott Windows-os GUI-nak, és nem is annyira produktívak (hiába hazudják azt róluk). Ezért érdemes lehet vmi hagyományos ablakkezelővel installálni a rendszert, mint pl. XFace, gnome-mate. A könnyítés kedvéért vannak olyan install médiumok, amik default-ból ezekkel teszik fel a rendszet, pl: Fedora XFCE spin, xUbuntu.
-
moriak
tag
válasz
jetarko
#6762
üzenetére
Kicsit előreszaladtam igen és osztom Jim-Y véleményét.
Én legalábbis úgy szoktam, hogy Maven modulos így nem csak horizontálisan (layerezés) hanem vertikálisan (modul) is szétszedem a projektet.
Nem érzem én sem azt, hogy ennek feltétlenül kettőnek kellene lennie, de természetesen Te dolgozol rajta. -
Jim-Y
veterán
válasz
jetarko
#6757
üzenetére
Sot, igazabol megoldhatod egyetlen projekttel is,
* Java eseten van ra lehetoseged egy JEE app segitsegevel, pl JSF MVC-vel. +resp. design.
* Vagy megfoghatod a dolgot JavaScript oldalon is, Hipszter leszek iojs-ben ugy, hogy Express framework, es valamilyen templating engine (pl Jade, vagy Markdown) segitsegevel csinalod meg az appot.** Vagy van egy harmadik, kettot otvozo very-hot-topic megoldas, hogy Isomorfic-usan csinalod meg a projektet, iojs es React segitsegevel. Ez azt jelenti, hogy az elso szerver request alkalmaval (vagy navigationnel) meg szerver oldalon allitod ossze a landing page-et, ezt kuldod el a kliensnek, majd onnantol kezdve ugy mukodik az oldal mint egy SPA. Eddig erre tobb okbol sem volt lehetoseg, de miota van node azota elmeletben mar lehetseges, gyakorlatban meg kellett a React js szeru realizacio, miszerint a React kepes lesz felismerni, hogy mar kliens oldali kornyezetben van, es kepes ugy futni. Ennel a megoldasnal meg a Meteor is emlitest erdemel.
Ugye az elso esetben nem uszod meg a JavaScriptet sem, utobbi ket esetben pedig csak JavaScriptet kell hasznalnod, igy fejlesztoi szempontbol meguszhato a context switching, mas problemak persze adodhatnak (mennyire mature, mennyire nagy a project, relacios/dokumentum orientalt, stb..).
Udv
-
Jim-Y
veterán
válasz
jetarko
#6755
üzenetére
Projekt1
======Java+REST endpointok+Data tier
Projekt2
======JavaScript kliens applikacio, akar Angularral ami AJAX segitsegevel hivja a Projekt1 REST szervizeit.
Ide ha kell mobilos nezet is, akkor 2 lehetoseged van:1: reszponziv design. PC, mobil, tablet minden bongeszoben nyitja meg az oldalt, es a layout igazodni fog a felbontashoz
2: hybrid mobil applikacio, Apache Cordova segitsegevel. (buzzwords: PhoneGap, Ionic, Touchstone). Ilyenkor egy mobilos applikaciot csinalsz (igen olyat amit feltolthetsz az AppStore-ba, Android Store-ba) es a build soran a cordova csinal neked egy build-browsert amit feltehetsz egy webszerverre.
Udv
-
moriak
tag
válasz
jetarko
#6743
üzenetére
"Ha jól értelmezem azt javaslod, hogy amit csak lehet json-ra építsek fel és akkor máshonnan is lehet hívogatni ha szükséges...."
Igen ez lenne a lényeg.
- Template engine-t nem tudod kihagyni, de az nem is probléma. Velocity maradhat persze.
- Amit még kihagytam, hogy nagyon elegáns tud lenni(és az ilyen apróságok fain pontok a szakdogában) ha verziózod a rest-es hívásokat. Ugyan is előfordulhat és erre a legjobb példa az android alkalmazás, hogy használja X ember az alkalmazást, de ha frissíted az alkalmazást és változik egy hívás akkor meg kell hagyni az eredeti hívást. Erre is keress utána érdemes.
- Ami még talán fontos lehet és szuper dolog az az adatbázis verziózás. Liquibase vagy Flyway amik szerintem jók, de kereshetsz alternatívát. -
#6744
Aethelstone
addikt
jetarko
#6740
-
moriak
tag
válasz
jetarko
#6740
üzenetére
"Nézetek" mellé írhatod az API-t is Controllerekbe, de persze az lenne a legszebb ha az API-val kommunikálnál teljesen minden front-end részről. A template-engine-t nem tudod elhagyni. Ajánlom a themyleaf-et, de ha sima JSP-s az sem para. Security része mind a kettőnek van az pedig kötelező egy webappnál.
Szép rest-api-design írható és sokkal flexibilisebb, angularral meg tökéletesen fog működni.
Springes youtube csatornán sok kiemelkedő videó van a fejlesztőktől.Szakdoga javaslat: legyen kevesebb, de minőségi. Figyelj az apróságokra. (cache, security, validáció, stb. stb.)
-
floatr
veterán
válasz
jetarko
#6639
üzenetére
FYI a message tag-en keresztüli adatkezelés úgy működik, hogy a properties állományt a classloader beolvassa egy map-be. Mivel semmi nem indokolja a dolgot, nem is tölti újra, de a memóriában tartja az adatokat. Ha "valami" megoldaná, hogy a map újratöltse magát, akkor teljesen mindegy hol tárolod kiindulásképpen.
Mint pl ez a megoldás: [link]
-
Cathfaern
nagyúr
válasz
jetarko
#6627
üzenetére
Template engineket nem ismerem, de angularjs-t valamennyire igen. Két esetben vágj, bele:
1. Egyszerű dolgok kellenek kliens oldalon
vagy
2. Hajlandó vagy rá jóval több időt rászánni, mint első ránézésre szükségesAngularjs tipikusan olyan framework, ami elsőre pofonegyszerűnek tűnik, és pillanatok alatt lehet benne csodás dolgokat összedobni. De ha valamiért nem jó az alapmegoldás, akkor meg nagyon bele kell mélyedni. Ez a kép tökéletesen igaz tapasztalataim szerint
[link] -
#6395
Aethelstone
addikt
jetarko
#6394
Aethelstone
addikt
válasz
jetarko
#6394
üzenetére
Ezt a "minden oldalon" megfogalmazást nem értem.
Általános szabály, hogy az adatbázis kezelését és az ehhez kapcsolódó hibakezelést 1 helyen oldjuk meg, az esetleges hibákat továbbdobjuk és a használat helyén csak ezeket kezeljük valamilyen módon. Nyilván ha Exception-t dobsz, akkor azt minden helyen kezelni kell, ahol használod.
-
#6393
Aethelstone
addikt
jetarko
#6390
Aethelstone
addikt
válasz
jetarko
#6390
üzenetére
Hát nem igazán értem, hogy ez mitől jobb annál, mint ha simán kiírnám, hogy pl: /home.
Kb. azért, amiért a konstansok használata jobb, mint a kódba égetett szöveg. Másrészt 15 kontroller összes path-ja mondjuk egy osztályból módosítható.
@Override azért van, mert nincs bemásolva az egész osztály, ami egyébként implementál egy interfészt, ami a jelen probléma szempontjából indifferens.
-
#6387
Aethelstone
addikt
jetarko
#6385
Aethelstone
addikt
válasz
jetarko
#6385
üzenetére
Persze.
Itt egy darab kontrollermetódus:
@Override
@RequestMapping(value=RestConstants.AppInfo.SERVICE_NAME, method = { RequestMethod.GET, RequestMethod.POST })
protected HttpEntity<byte[]> processRequest(HttpServletRequest request) {
return super.doIt(RestConstants.AppInfo.SERVICE_NAME, request);
}és a hozzátartozó interfész:
public interface RestConstants {
@RestApiFunction(name = "Application info", description = "Provides information about the application", responseClass = RestAppInfoBean.class)
public interface AppInfo {
@RestApiRequestParameter(service = true, description = "")
static final String SERVICE_NAME = "appinfo";
}
}Ez egy restapi implementáció darabja, pár saját annotációval megspékelve.
Mondjuk ez egy régebbi megvalósítás, ami még nem Enum-ot használ, azt éppen keresem a projektben -
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. -
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.
-
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.
-
#6211
Aethelstone
addikt
jetarko
#6179
-
#6190
Aethelstone
addikt
jetarko
#6179
Aethelstone
addikt
válasz
jetarko
#6179
üzenetére
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....
-
boost
veterán
válasz
jetarko
#6146
üzenetére
Szia,
szerintem szakdogára a primefaces teljesen jó. Ott nem kell azzal foglalkoznod, hogy mi lesz vele 5 év múlva (mivel JSF kompatibilis, ezért max lecseréled egy másik frontendre, ellentétben a GWT-vel, és a vaadinnal), vagy hogy hogy is van a licenszelése (mert szakdoga)Egyszeru" benne programozni, és látványos is, szóval pont az, ami egy szakdogafeladatra kell.
Offtopic: Szakdogánál arra vigyázz, hogy mindig a feladatra koncentrálj, és az azon kívül eso", de szükséges dolgokat a leheto" legegyszerübben oldd meg. Tehát, ha esetedben a Primefaces vagy GWT csak egy eszköz, és nem a szakdoga tárgya , akkor gyorsan válassz ki egyet, és lépj tovább, ne merülj el a részletekben.ùgyis lesz elég problémád a szakdoga tárgyával
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Dell G3 Gamer laptop (2TB SSD, 32GB Ram, 4GB Videókártya, FullHD kijelző, szép állapotban)
- Thinkpad T14 Gen5 14" FHD+ IPS Ultra 5 135H 16GB 512GB NVMe ujjlolv IR kam gar
- Használt gamer/ workstation laptop felvásárlás TÉNYLEG magas áron!
- Intel Core Ultra 7 265 /// Bontatlan, Teljesen Új // Üzletből, Számlával és Garanciával
- Csere-Beszámítás! Ryzen 9 9950X Processzor!
- Telefon felvásárlás!! iPhone 14/iPhone 14 Plus/iPhone 14 Pro/iPhone 14 Pro Max
- LG 42C3 - 42" OLED EVO - 4K 120Hz 0.1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - A9 Gen6 CPU
- ÁRGARANCIA!Épített KomPhone Ryzen 5 4500 16/32/64GB RAM RTX 3050 6GB GAMER PC termékbeszámítással
- Bowers/Wilkins Px7 S2 fejhallgatók
- AKCIÓ! GIGABYTE B360 i5 9600K 16GB DDR4 512GB SSD RX 7600 8GB Rampage SHIVA Zalman 600W
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest