- Sony Xperia 1 VII - Látod-e, esteledik
- Samsung Galaxy Watch8 - Classic - Ultra 2025
- Samsung Galaxy A54 - türelemjáték
- iPhone topik
- Android alkalmazások - szoftver kibeszélő topik
- Samsung Galaxy S25 - végre van kicsi!
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Magisk
- Nagyobb kijelzőt kapott az olcsóbb Motorola Razr 50 is
- Köredzésen járt az Exynos 1680
Hirdetés
Új hozzászólás Aktív témák
-
-
#39560925
törölt tag
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.
-
#39560925
törölt tag
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.
-
#39560925
törölt tag
válasz
Aethelstone #7926 üzenetére
szerintem 1.8 kéne legyen a minimum minden új projektnél.
-
#39560925
törölt tag
válasz
Aethelstone #7923 üzenetére
1.7????
-
#39560925
törölt tag
summon Sk8erPeter
-
#39560925
törölt tag
válasz
Sk8erPeter #7838 üzenetére
szép a színe
-
#39560925
törölt tag
15-ös Idea loading screenje megb*sz.
-
#39560925
törölt tag
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"
-
#39560925
törölt tag
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.
-
#39560925
törölt tag
válasz
WonderCSabo #7761 üzenetére
De szakdolgozat, nálunk ott az embernek van beleszólása a választott technológiákba.
-
#39560925
törölt tag
válasz
WonderCSabo #7758 üzenetére
JavaFX akkor is korszerűbb lenne.
-
-
#39560925
törölt tag
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.
-
#39560925
törölt tag
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?
-
#39560925
törölt tag
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?
-
#39560925
törölt tag
válasz
Aethelstone #7714 üzenetére
persze, de az az IDE kezelésben még csak a level 1.
-
#39560925
törölt tag
TomEE-val játszadozom, egész jó cucc. Persze a Spring Boot-nak közelében sincs, de kezdetnek jó. Spring fanboy lettem
-
#39560925
törölt tag
Szerintetek egy 512MB RAM-os Ubuntun futni fog egy egyszerű Spring boot app és egy MySQL szerver?
-
#39560925
törölt tag
Mi a legolcsóbb megoldása egy MySQL-t használó Spring bootos backend futtatásának nyilvános felhőben, vagy szerveren?
-
#39560925
törölt tag
válasz
Aethelstone #7593 üzenetére
a Java halott
-
#39560925
törölt tag
Wow, ez a Spring Boot és Spring Data JPA elég kényelmes. Hogy nem használtam önlabra...
-
#39560925
törölt tag
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?
-
#39560925
törölt tag
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?
-
#39560925
törölt tag
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.
-
#39560925
törölt tag
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.
-
#39560925
törölt tag
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.
-
#39560925
törölt tag
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]
-
#39560925
törölt tag
Mivel nincs scala topik, itt teszem fel a kérdést: mi a legjobb oktatóanyag a neten?
-
#39560925
törölt tag
válasz
norbert1998 #7336 üzenetére
kijelölöd a sorokat és nyomsz egy tab-ot
-
#39560925
törölt tag
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?
-
#39560925
törölt tag
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.
-
#39560925
törölt tag
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.
-
#39560925
törölt tag
É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.
-
#39560925
törölt tag
válasz
#39560925 #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"
-
#39560925
törölt tag
"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 -
#39560925
törölt tag
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;
} -
#39560925
törölt tag
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;
} -
#39560925
törölt tag
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.
-
#39560925
törölt tag
Ha már Hibernate. Ez WTF?
-
#39560925
törölt tag
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.
-
#39560925
törölt tag
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.
-
-
#39560925
törölt tag
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.
-
#39560925
törölt tag
válasz
#39560925 #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.
-
#39560925
törölt tag
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.
-
#39560925
törölt tag
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.
-
#39560925
törölt tag
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?
-
#39560925
törölt tag
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.
-
#39560925
törölt tag
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.
-
#39560925
törölt tag
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Honor MagicBook 16 Ryzen 5 5600H 16GB 256GB FHD 144Hz
- iKing.Hu -Xiaomi 14T Pro Titan Gray Használt, karcmentes állapotban 12 GB RAM / 512 GB tárhely
- HIBÁTLAN iPhone 13 512GB Starlight -1 ÉV GARANCIA - Kártyafüggetlen, MS3076, 100% Akkumulátor
- Logitech G513 Carbon Tactile DE (2) (ELKELT)
- Epson Expression 12000 XL A3 síkágyas fotószkenner
Állásajánlatok
Cég: FOTC
Város: Budapest