- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- NASsoljunk: ZyXEL NSA-310 és az FFP
- Mr. Y: Motoros sztorik #06
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Magga: PLEX: multimédia az egész lakásban
- Őskoczka
- sziku69: Fűzzük össze a szavakat :)
- gban: Ingyen kellene, de tegnapra
- GoodSpeed: Samsung Galaxy SmartTag2-esek a tolvajok ellen!
Új hozzászólás Aktív témák
-
#8042
Oppenheimer
nagyúr
Sempronius89
#8041
-
#7949
Oppenheimer
nagyúr
Aethelstone
#7948
Oppenheimer
nagyúr
válasz
Aethelstone
#7948
üzenetére
nincs, de érdeklődöm. habár el se olvastam rendesen a kérdését, utólag elolvasva tényleg felesleg volt feltennem.
-
#7938
Oppenheimer
nagyúr
Aethelstone
#7937
Oppenheimer
nagyúr
válasz
Aethelstone
#7937
üzenetére
Dehogynem ugyanaz a téma. Bambano új projektet kezd, és erre öntökönrúgás nem Java 8-at használni.
"Az 1.7-es javaval ugyanolyan jól lehet dolgozni felteszem, mint az 1.8-al."
Ez pedig nem igaz, hisz nincsenek funkcionális elemek az 1.7-ben.
-
#7927
Oppenheimer
nagyúr
Aethelstone
#7926
Oppenheimer
nagyúr
válasz
Aethelstone
#7926
üzenetére
szerintem 1.8 kéne legyen a minimum minden új projektnél.
-
#7924
Oppenheimer
nagyúr
Aethelstone
#7923
Oppenheimer
nagyúr
válasz
Aethelstone
#7923
üzenetére
1.7????
-
#7895
Oppenheimer
nagyúr
Oppenheimer
nagyúr
summon Sk8erPeter
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#7840
Oppenheimer
nagyúr
Sk8erPeter
#7838
Oppenheimer
nagyúr
válasz
Sk8erPeter
#7838
üzenetére
szép a színe
-
#7837
Oppenheimer
nagyúr
Oppenheimer
nagyúr
15-ös Idea loading screenje megb*sz.
-
#7812
Oppenheimer
nagyúr
ToMmY_hun
#7810
Oppenheimer
nagyúr
válasz
ToMmY_hun
#7810
üzenetére
Pont tegnap kezdtem én is használni, mert a sima Collenctions.synchronizedList() iterátora is ConcurrentModificationException-öket dobált.
Amire figyelj, hogy a CopyOnWriteArrayList-et nem lehet Collections.sort-tal rendezni: "Element-changing operations on iterators themselves (remove, set, and add) are not supported. These methods throw UnsupportedOperationException."Ezen kívül rossz tapasztalatom egyelőre nincs vele. Nálam ezért volt indokolt a használata: "useful when you cannot or don't want to synchronize traversals, yet need to preclude interference among concurrent threads"
-
#7785
Oppenheimer
nagyúr
emvy
#7784
-
#7776
Oppenheimer
nagyúr
zserrbo
#7775
Oppenheimer
nagyúr
válasz
zserrbo
#7775
üzenetére
Először is: Javaban mindig érték szerinti átadás van. Ez azt jelenti, hogy amikor myArrList.addAll meghívódik, akkor a yourArrList-ben tárolt referenciák lemásolódnak.
yourArrList elemei: a "three" és "four" stringek. addAll meghívása után mindkét listában van 1-1 referencia ezekre a stringekre.
Ha az egyik listában kitörlöd a referenciát, az a másik listára természetesen nem lesz hatással. Ha viszont a referencián keresztül megváltoztatod objektum állapotát, akkor az a másik listából elérve is látszódni fog. A példa ott sántít, hogy a String immutable.
-
#7763
Oppenheimer
nagyúr
WonderCSabo
#7761
Oppenheimer
nagyúr
válasz
WonderCSabo
#7761
üzenetére
De szakdolgozat, nálunk ott az embernek van beleszólása a választott technológiákba.
-
#7760
Oppenheimer
nagyúr
WonderCSabo
#7758
Oppenheimer
nagyúr
válasz
WonderCSabo
#7758
üzenetére
JavaFX akkor is korszerűbb lenne.
-
#7739
Oppenheimer
nagyúr
emvy
#7738
-
#7733
Oppenheimer
nagyúr
WonderCSabo
#7732
Oppenheimer
nagyúr
válasz
WonderCSabo
#7732
üzenetére
Az átmenet nem menne egyik napról a másikra. Az új rendszereken a 2 runtime párhuzamosan elérhető lenne, mint ahogy iOS-re is lehet fejleszteni Objective-C-ben és Swiftben is. Aztán 5-10 év alatt a JVM runtime szépen kikopna. Tény, hogy csomó munkájuk az ART-vel kukába menne.
-
#7731
Oppenheimer
nagyúr
WonderCSabo
#7730
Oppenheimer
nagyúr
válasz
WonderCSabo
#7730
üzenetére
Groovy az nagyon lassú kódot eredményez, nem tudom, hogy mobilon jó ötlet lenne-e. Miért ne írhatnának új runtime-ot, amiben nem JVM van?
-
#7721
Oppenheimer
nagyúr
WonderCSabo
#7720
Oppenheimer
nagyúr
válasz
WonderCSabo
#7720
üzenetére
Nem tudom, hogy a Java 8 mennyit nyomhat itt a latba, ezt lehetetlen számszerűsíteni. Hallottál olyanról, hogy valahol azért döntöttek Java mellett, mert a 8 olyan fasza? Amúgy nekem nagyon bejönnek a labdák meg a streams API.
Amúgy azt tudták, hogy a Jigsaw-os modularizáció rossz hatással lesz a teljesítményre?
-
#7715
Oppenheimer
nagyúr
Aethelstone
#7714
Oppenheimer
nagyúr
válasz
Aethelstone
#7714
üzenetére
persze, de az az IDE kezelésben még csak a level 1.
-
#7650
Oppenheimer
nagyúr
Oppenheimer
nagyúr
TomEE-val játszadozom, egész jó cucc. Persze a Spring Boot-nak közelében sincs, de kezdetnek jó. Spring fanboy lettem
-
#7625
Oppenheimer
nagyúr
Oppenheimer
nagyúr
Szerintetek egy 512MB RAM-os Ubuntun futni fog egy egyszerű Spring boot app és egy MySQL szerver?
-
#7603
Oppenheimer
nagyúr
Oppenheimer
nagyúr
Mi a legolcsóbb megoldása egy MySQL-t használó Spring bootos backend futtatásának nyilvános felhőben, vagy szerveren?
-
#7594
Oppenheimer
nagyúr
Aethelstone
#7593
Oppenheimer
nagyúr
válasz
Aethelstone
#7593
üzenetére
a Java halott
-
#7535
Oppenheimer
nagyúr
Oppenheimer
nagyúr
Wow, ez a Spring Boot és Spring Data JPA elég kényelmes. Hogy nem használtam önlabra...
-
#7503
Oppenheimer
nagyúr
emvy
#7502
Oppenheimer
nagyúr
Ha a1 nyom egy yield-et, akkor a1-a10 es b1-b10 szalak kozul valamelyik fog utemezesre kerulni.
Ez alapján annyira random a yield, hogy az is lehet hogy a1 blocked állapotba kerül (hisz másképp nem kerülhetne ütemezésre a1-a10 közül más, mert az a1 foglalja a monitort), de az is lehet, hogy nem változik semmi?
A queued ne tevesszen meg, nincs sorrendiseg ertelmezve a varakozo szalak kozott.
Ez világos.
A queued az, ami nem var semmilyen monitoron, csak preemptalva lett (vagy csak elinditottak, de meg nem kerult utemezesre).
Csak a tisztánlátás végett: ha a példánkban a1 van az A objektum monitorában, és b1 a B monitorában, akkor a1 és b1 ami queued (vagy épp running, attól függ mi van beütemezve).
Yielddel nem csak a1 és b1 közötti ütemezést lehetne befolyásolni?
-
#7501
Oppenheimer
nagyúr
Oppenheimer
nagyúr
alap threading kérdésem lenne...
A képen milyen állapot a queued? Ez alapján a yield csak jelzi, hogy hajlandó a szál feladni a futási jogát, és JVM dönt, hogy fut-e tovább.
TFH van 1 CPU mag, 1 A objektum amire szinkronizál 10 thread (a1 .. a10) és, 1 B objektum, amire szinkronizál másik 10 thread (b1 .. b10).
Az a1 .. a10 szálak között az ütemezés úgy zajlik, hogyha a1 szál lemond a futási jogáról, akkor (timed) waiting állapotba, és az A objektum monitor sorábol bekerül másik szál a monitorba, ami futhat.
Közben ettől függetlenül a működik a preemptív ütemezés a JVM-en (és alatta a host oprendszeren), és passzolgatja a futási jogot az A objektum monitorában és B objektum monitorában lévő szálak között.
Jól gondolom, hogyha a yield meghívódik, akkor az egy jelzés a JVM-nek, hogy az éppen futó a1 szál helyett beütemezheti a B objektum monitorában lévő b1 szálat, és nem fogja befolyásolni azt, hogy az A objektum monitorában és monitor sorában kik állnak?
-
#7472
Oppenheimer
nagyúr
PumpkinSeed
#7470
Oppenheimer
nagyúr
válasz
PumpkinSeed
#7470
üzenetére
"Valamiért nekem villog össze vissza"
Igen, az animáció akkor is be van kapcsolva és lassabb az animáció (50ms), mint ahogy húzogatod a csúszkát. Akkor is animál ha gépelsz, de annyira gyorsan kevesen írnak hogy azt ne tudja követni az animáció. Csúszkánál kiviszem majd.
Tudom, hogy nem igényes a design, de mint írtam a frontend teljesen újra lesz írva Angularban, így ezekkel már nem foglalkozok. Inkább olyan funkcionalitásbeli ötleteket vártam, mint social login, ismerőseid tevékenységeinek mutatása (megnézett, értékelt, listára rakott egy filmet) egy timelineon és hasonlók.
-
#7469
Oppenheimer
nagyúr
Oppenheimer
nagyúr
Itt van a kis béna webapp ami miatt annyit kérdeztem mostanság.
Ha elmenne a netem, azért nem vállalok felelősséget.Frontend egy összegányolt single page app, sima html + jquery kombóval, azt majd újraírom angularral. A kinézetet ötévesek tervezték.
Regisztrációs felület még nincs, ezért csináltam a topiknak egy usert:
user: JavaHurkák
pwd: password3 hónappal ezelőtti IMDB adatbázisból dolgozik (akkor töltöttem le).
Elsősorban azért raktam be ide, hogy aki tud, az írhatna ötleteket új funkciókhoz.
-
#7447
Oppenheimer
nagyúr
dabadab
#7446
-
#7427
Oppenheimer
nagyúr
Oppenheimer
nagyúr
Sziasztok, egy jó kis SO kérdéssel jönnék. Ha valami nem világos a kérdésemben, vagy több információ kell, akkor rendelkezésre állok.
-
#7390
Oppenheimer
nagyúr
emvy
#7383
Oppenheimer
nagyúr
A productivity és a több paradigma miatt akarom megtanulni. Olvastam ellenvéleményeket, pont azokat a hátrányokat írták, amit te. Igaz olyat nem hallottam, hogy scalaról visszamentek javara, viszont csomó beszámolót olvastam a neten, hogy miért választották a scalat a következő projektünk nyelvének. [link] [link]
-
#7378
Oppenheimer
nagyúr
Oppenheimer
nagyúr
Mivel nincs scala topik, itt teszem fel a kérdést: mi a legjobb oktatóanyag a neten?
-
#7337
Oppenheimer
nagyúr
norbert1998
#7336
Oppenheimer
nagyúr
válasz
norbert1998
#7336
üzenetére
kijelölöd a sorokat és nyomsz egy tab-ot
-
#7310
Oppenheimer
nagyúr
Oppenheimer
nagyúr
Most nem vagyok otthon, de út közben nem hagy nyugodni a gondolat. Fut a webapp a gépen, és ha a host gép böngészőjéből nyitok meg egy oldalt, akkor szépen a frontendtől elmegy rest hívás a backendhez, meghívódik a controller megfelelő metódusa, és visszaadja amit várok. Viszont ha másik gépről/telefonról nyitom meg az oldalt böngészőben, a host ip címét beírva, akkor a frontend elküldi a rest hívást a backendnek, a dispatcher elkezdi feldolgozni, de nem jut el a request a controllerig. Elkezdtem, de nem volt időm végignézni mit csinál a dispatcher (doDispatch metódus) és min hasal el, mert indulnom kellett, de jó lenne tudni, hogy mégis mitől lehet ez. Van valami gyakori hiba amit elkövettem?
-
#7276
Oppenheimer
nagyúr
Aethelstone
#7274
Oppenheimer
nagyúr
válasz
Aethelstone
#7274
üzenetére
Durvának hangzik, mert leírva, hogy label, az ember az assemblyre asszociál, de sima for-ból kiugrásra is oda lehet tenni, hogy még egyértelműbb legyen az amúgy is triviális ciklustörés, amikor valaki ránéz.
-
#7273
Oppenheimer
nagyúr
Aethelstone
#7272
Oppenheimer
nagyúr
válasz
Aethelstone
#7272
üzenetére
szerintem is inkább egy break, mint még 1 feltétel a ciklusfejlécben. főleg, hogy javában lehet labelt tenni, úgy pláne nem olvashatatlan szerintem.
-
#7249
Oppenheimer
nagyúr
floatr
#7248
Oppenheimer
nagyúr
Értem az összes annotáció jelentését, de ennyit kézzel írni... hát nem volt sok kedvem. 5 perc alatt generálni azt 800 sornyi kódot a model packagebe azért jóval hatékonyabb megoldás. Generálás után meg beleszerkesztettem úgyis mindbe, hogy nekem megfelelően működjön.
Nos igen, a @GeneratedValue kelleni fog.
-
#7247
Oppenheimer
nagyúr
Oppenheimer
#7246
Oppenheimer
nagyúr
válasz
Oppenheimer
#7246
üzenetére
Fogtam az adatbázist és toltam rá alter tablet, átneveztem az oszlopot arra, amit a hibernate annyira használni akart, és már jó. Megoldást nem találtam, mindenesetre nagyon furcsa.
-
#7246
Oppenheimer
nagyúr
Oppenheimer
#7244
Oppenheimer
nagyúr
válasz
Oppenheimer
#7244
üzenetére
Egyébként az MpaaRatings-zel ugyan ezt csinálja. Ott is nem létező, id oszlopot keres az adatbázisban. Ezekről tudni kell, hogy én nyomtam alter table-t utólag a táblákon, hogy legyen elsődleges kulcs bennük. Pl:
alter table movietime2.movies2actors add m2aid int primary key auto_increment;Ez azóta is jó egyébként, a movies2actors kapcsolótáblát boldogan tudom használni.
Ha explicit megadom az MpaaRatingsEntity-hez, hogy mi a join table és mik a join columnok, akkor se jó:
@JoinTable(name = "mpaaratings", catalog = "movietime2", schema = "",
joinColumns = @JoinColumn(name = "movieid", referencedColumnName = "movieid", nullable = false),
inverseJoinColumns = @JoinColumn(name = "mpaaratingsId", referencedColumnName = "mpaaratingsId", nullable = false))"Missing column: mpaaratings_id in movietime2.mpaaratings"
Holott meg:
-
#7244
Oppenheimer
nagyúr
floatr
#7243
Oppenheimer
nagyúr
"Nekem a hibaüzenetből eleve az gyanús, hogy a táblában más néven keresi az ID-t, mint ahogy deklaráltad volna."
Ok, de mire gyanakszol?
Miért "ahogy deklaráltad volna"? Nem volna, hanem így van deklarálva: genreId. Meg is van adva neki, hogy így keresse.
"A helyedben én az @Id és @Column annotációkat nem a metódusokra tenném."
Nem én tettem, az Idea volt. Tökéletesen működik minden, ha kiveszem a GenresEntity osztályt."Az meg a másik, hogy ha csak nem muszáj, én nem babrálnám a hibernate saját elnevezési stratégiáját."
Ezt kifejtenéd kérlek bővebben? Mire gondolsz?
Ha az entitások és az attribútimaik neveire gondolsz, akkor azok 2 okból alakultak így:
1) adatbázisban a nevek
2) Ideában a Generate persistence mapping by database schema wizardból -
#7242
Oppenheimer
nagyúr
Mukorka
#7241
Oppenheimer
nagyúr
válasz
Mukorka
#7241
üzenetére
Intellij Idea tette bele a generálás során. Ezen én is gondolkodtam, de mivel nem fogok hozzájuk nyúlni, egyelőre nem akartam bántani őket.
"MoviesEntity -ben hol a characters mappelése?"
Látod, a hsz-ben, de itt van mégegyszer:
@OneToMany(mappedBy = "movie")
public List<Movies2ActorsEntity> getCharacters() {
return characters;
} -
#7240
Oppenheimer
nagyúr
emvy
#7239
Oppenheimer
nagyúr
Először is itt egy működő példa |Movies2Actors| *----1 |Movies|:
MoviesEntity class:
@JsonIgnore
private List<Movies2ActorsEntity> characters;
@JsonIgnore
private List<GenresEntity> genres;
...
@OneToMany(mappedBy = "movie")
public List<Movies2ActorsEntity> getCharacters() {
return characters;
}
@OneToMany(mappedBy = "movie")
public List<GenresEntity> getGenres() {
return genres;
}Movies2ActorsEntity class:
private int m2aid;
private int movieid;
private int actorid;
private String asCharacter;
private ActorsEntity actor;
private MoviesEntity movie;
...
@Id
@Column(name = "m2aid", nullable = false, insertable = true, updatable = true)
public int getM2aid() { return m2aid; }
@ManyToOne
@JoinColumn(name = "movieid", referencedColumnName = "movieid", nullable = false)
public MoviesEntity getMovie() {
return movie;
}És akkor a |Genres| *----1 |Movies|
GenresEntity:
private int movieid;
private String genre;
private int genreId;
@JsonIgnore
private MoviesEntity movie;
...
@Id
@Column(name = "genreId", nullable = false, insertable = true, updatable = true)
public int getGenreId() {
return genreId;
}
@ManyToOne
@JoinColumn(name = "movieid", referencedColumnName = "movieid", nullable = false)
public MoviesEntity getMovie() {
return movie;
} -
#7238
Oppenheimer
nagyúr
emvy
#7237
Oppenheimer
nagyúr
De, persze, ezt a MoviesEntity-vel joinolom. Azóta az is belekerült az SO kérdésbe. De a kérdés inkább az, hogy a hibernate honnan szedi ezt a genre_id-t, amikor elvileg helyesen fel van annotálva, hogy genreId van az adatbázisban. MoviesEntity és Movies2ActorsEntity között ugyan ilyen OneToMany kapcsolat van és működik, ahhoz képest semmit sem csináltam másképp.
-
#7236
Oppenheimer
nagyúr
Oppenheimer
nagyúr
Ha már Hibernate. Ez WTF?
-
#7213
Oppenheimer
nagyúr
Oppenheimer
#7212
Oppenheimer
nagyúr
válasz
Oppenheimer
#7212
üzenetére
Persze értem a csomagolás hátrányát is, de szerintem kisebb, mint a másiknak.
-
#7212
Oppenheimer
nagyúr
Mukorka
#7211
-
#7210
Oppenheimer
nagyúr
Szmeby
#7208
Oppenheimer
nagyúr
Alvás helyett gondolkodtam floatr hozzászólásán. Biztos, hogy JSON serialization-ről beszélt. Ha a kapcsolatokra teszek @JsonIgnore-t, akkor amikor csak alap információk kellenek az entitásokról, jól fog működni parszolás. Amikor pedig egy nagy objektumot küldenék, pl Movie, és benne minden kapcsolódó adattal, akkor ilyen esetekre definiálnék wrapper osztályt, és benne lenne minden szükséges adat egy mezőként.
Pl:
public class MovieWrapper {
private MoviesEntity movie;
private ArrayList<ActorsEntity> actors;
private ArrayList<WritersEntity> writers;
// többi kapcsolat
...
// getterek, setterek
}Ezt az objektumot gyönyörűen meg tudom konstruálni a business logic layerben, amikor még van hibernate sessionöm, és így nincs konverzió, kódduplikáció, csak 1 kis extra karbantartás.
Kérdés: Jackson tudni fogja ezt parszolni? Most nem tudom kipróbálni, mert már aludni akarok, és mobilról írtam.
-
#7204
Oppenheimer
nagyúr
Aethelstone
#7203
Oppenheimer
nagyúr
válasz
Aethelstone
#7203
üzenetére
Már megírtam a DTO konverziót, nagyon szép lett.
Ezt azért elrakom könyvjelzőkbe, hátha kell még. -
#7200
Oppenheimer
nagyúr
floatr
#7199
-
#7196
Oppenheimer
nagyúr
Oppenheimer
#7195
Oppenheimer
nagyúr
válasz
Oppenheimer
#7195
üzenetére
Ez így nagyon nem pálya, 1 weboldal betöltéséhez n*100 http üzenetváltás kéne. Tanácstalanná váltam
-
#7195
Oppenheimer
nagyúr
Mukorka
#7194
Oppenheimer
nagyúr
válasz
Mukorka
#7194
üzenetére
Lehet kezdek rájönni. Ignorálni kéne alapból minden kapcsolatot, és kézzel intézni őket.
hmm... de ha @JsonIgnore-t rakok rájuk, akkor sehogy sem tudom majd serializálni őket JSON-ba.
Minden bizonnyal az van amit írsz, de nekem nem világos miért akarja a Jackson bejárni az egész adatbázisomat.
Ha sikerülne neki, alsó hangon 8 gigás lenne a HTTP response bodyja. -
#7193
Oppenheimer
nagyúr
Oppenheimer
#7192
Oppenheimer
nagyúr
válasz
Oppenheimer
#7192
üzenetére
Ez nem fog működni, baja van a Jacksonnak.
Pl filmeknél direkt gettelek minden színészt, írót és producert, mégse hajlandó létrehozni belőle a json objektumot:
Could not write content: failed to lazily initialize a collection of role: com.movietime.model.MoviesEntity.actors, could not initialize proxy - no Session (through reference chain: com.movietime.model.MoviesEntity.
Nem tudom minek akar itt proxyzni, amikor be vannak töltve neki a dolgok, és megfelelően annotálva vannak az entitások is, pl MoviesEntity:
@JsonIdentityInfo(generator = ObjectIdGenerators.PropertyGenerator.class, property = "movieid")Ez csak az egyik baj, a másik az, ha csak listázni akarok filmeket, akkor fölösleges betölteni minden filmhez minden adatot, elég csak a címet, rendezőt és mondjuk két színész nevét kiírni a listában. A többit akkor kéne csak lekérdezni az adatbázisból, ha rákattint valamelyikre a felhasználó. Ha sikerülne is rávenni a Jacksont, hogy legalább akkor csinálja a dolgát, amikor minden információ megvan hozzá, ez a funkció még akkor se működne.
-
#7192
Oppenheimer
nagyúr
Szmeby
#7190
Oppenheimer
nagyúr
Többnyire gúglit nézek, aztán onnan mindenfelé vezetnek utaim, többek között a hibernate doksihoz is.
Nekem az 1-es megoldás tetszik a legjobban, és ha nem jön be, akkor megnézem a többivel. A gond lehet, hogy valójában nem is itt van, hanem a JSON parserrel, de ez még kiderül, mindenesetre most nőtt annyival a tudásom, hogy jó ideig ellegyek vele.
Egyébként több helyen is olvastam, hogy a hibernatenek tudnia kéne kezelni eager fetchelés közben az ilyen ciklikus, 2 irányú many-to-many kapcsolatokat, de úgy látszik a gyakorlatban még sincs így.
(#7191) emvy: Hmm, logikusan tűnik.
-
#7189
Oppenheimer
nagyúr
Mukorka
#7188
Oppenheimer
nagyúr
válasz
Mukorka
#7188
üzenetére
Köszönöm, akkor nincs mese, ez az üzleti logika része lesz, és kézzel rakom össze. Igen, nyilván a hibernate se egy SQL query-vel oldaná meg, de feltételezem, hogy mivel alacsonyabb szinten van, ezért ha lenne benne ilyen lehetőség, jobban optimalizált megoldás lenne, mint az enyém.
-
#7187
Oppenheimer
nagyúr
Oppenheimer
nagyúr
Ha egy service layer-beli osztályban van egy @Transactional metódus, ami meghívja egy DAO osztály metódusát, amely osztályban be van injektálva egy EntityManager @PersistenceContext-tel, akkor ennek az EntityManagernek a perzisztenciakontextusa megmarad a hívó service layer-beli metódusban is?
Most kísérleti jelleggel azt csinálom, hogy a RestController osztály metódusát jelöltem @Transactional-nek és az közvetlen hívja a DAO osztály metódusát, ami egy MovieEntityvel tér vissza, de amikor a RestController metódusa átadja a Jackson JSON parsernek a MovieEntityt, akkor mintha már nem lenne meg a perzisztenciakontextus, mert a hibernate proxy objektum megszűnt, és nem éri el a kapcsolódó entitásokat:
com.fasterxml.jackson.databind.JsonMappingException: failed to lazily initialize a collection of role: com.movietime.model.ActorsEntity.movies, could not initialize proxy - no Session
Próbálkoztam azzal, hogy EAGER fetchinget állítok be minden Entitás osztályban, és akkor nem lenne ilyen probléma, de akkor a túl sok bi-directional many-to-many asszociáció miatt megbolondul a hibernate és a Query.getSingleResult() már vissza se tér.
Kerestem olyan megoldást is, hogy lehessen korlátozni az EAGER fetching mélységét, de csak olyat találtam, hogy a LAZY-t lehet optimalizálni @BatchSize-zal. Viszont ez nekem nem jó, mert a JSON parserig már nem jut el a hibernate sessionje, vagy persistence contextje, nem tudom hogy hívjam.
Csinálhatnám azt is, hogy a DAO rétegben olyan lekérdezéseket írok kézzel, hogy lekérem a filmet, aztán lekérem a hozzá kapcsolódó színészeket, producereket, mindenkit, és összetákolom a kapcsolatokat, de ez egyrészt nagyon lábbal hajtós, másrészt az adatbáziskapcsolattal nagyon pazarló lenne. Jobb lenne, ha ezt a hibernate elintézné.
Az is jó lenne, ha a @Transactional úgy működne, ahogy a hsz elején a kérdésben feltettem, de nekem úgy tűnik, mintha nem így történne. Lehet azért, mert nem JTA típusú tranzakcióim vannak, hanem JPA?
-
#7186
Oppenheimer
nagyúr
Oppenheimer
nagyúr
Vannak adatbázis entitásaim amik körbehivatkoznak egymásra, például MoviesEntity ismer csomó ActorsEntity-t és vica-versa. Ezeket az entitásokat akarom REST-en keresztük JSON-nel elérhetővé tenni, méghozzá úgy, hogyha jön egy GET request egy MoviesEntity-re, akkor fetchelje le a hozzátartozó Actorokat, Producereket, stb-t, de ne tovább. Ez sikerül is az alábbi módon:
MoviesEntity:
@JsonManagedReference
private List<ActorsEntity> actors;
...
@ManyToMany(fetch = FetchType.EAGER)
@JoinTable(name = "movies2actors", catalog = "movietime2", schema = "", joinColumns = @JoinColumn(name = "movieid", referencedColumnName = "movieid", nullable = false), inverseJoinColumns = @JoinColumn(name = "actorid", referencedColumnName = "actorid", nullable = false))
public List<ActorsEntity> getActors() {
return actors;
}ActorsEntity:
@JsonBackReference
private List<MoviesEntity> movies;
...
@ManyToMany(mappedBy = "actors") // LAZY fetching is default
public List<MoviesEntity> getMovies() {
return movies;
}Ez rendben is van. Viszont azt is szeretném, hogyha valaki egy Actor-t kérne GET requesttel, akkor ugyan úgy kapja meg az 1 távolságra lévő kapcsolódó entitásokat is (pl milyen filmekben játszott).
Erre nincs ötletem, nem is nagyon találtam neten semmit. Esetleg valaki tudja mi ilyenkor a teendő, vagy ha valaki jobban gúglizik, mint én, az is nagy segítség volna.
conditional annotiation ha lenne, milyen jó lenne.
-
#7185
Oppenheimer
nagyúr
szcsaba1994
#7184
Oppenheimer
nagyúr
válasz
szcsaba1994
#7184
üzenetére
újabb verzióval fordítottad, mint amilyen JRE van a gépeden. szedd le a JRE 1.8-at és állítsd át a java HOME-ot arra.
-
#7182
Oppenheimer
nagyúr
CJ19
#7180
Oppenheimer
nagyúr
![;]](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?:))
- ASUS routerek
- Lexus, Toyota topik
- AliExpress tapasztalatok
- iPhone topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Székesfehérvár és környéke adok-veszek-beszélgetek
- MIUI / HyperOS topik
- Hegesztés topic
- Okosóra és okoskiegészítő topik
- További aktív témák...
- AMD Ryzen 7 5700X processzor eladó /Garanciás/
- Xbox Series S + 2 kontroller
- Dell laptop eladó i5 11. gen, 8GB RAM, 512GB SSD, újszerű állapotban!
- Bomba ár! HP EliteBook Folio 1040 G1 - i5-G4 I 8GB I 256GB SSD I 14" HD+ I Cam I W10 I Garancia!
- Bomba ár! HP Elitebook Folio 9470M - i5-3GEN I 8GB I 256GB SSD I 14" I DP I Cam I W10 I Garancia!
- Új, verhetetlen alaplap sok extrával!
- Telefon felvásárlás!! Xiaomi Redmi Note 12, Xiaomi Redmi Note 12 Pro, Xiaomi Redmi Note 12 Pro+
- AKCIÓ! GIGABYTE GA-Z170X-UD3 Z170 chipset alaplap garanciával hibátlan működéssel
- Telefon felvásárlás!! Samsung Galaxy A20e/Samsung Galaxy A40/Samsung Galaxy A04s/Samsung Galaxy A03s
- Dell USB-C dokkolók: (K20A) WD19/ WD19S/ WD19DC + 130W, 180W, 240W töltők
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest