- Hamarosan megkezdődik a nubia 2,8K-s táblagépének szállítása
- Barátokká váltak az eddig rivális AI-óriások
- ASUS blog: Ideális olcsó utazós gép lett az új Vivobook S14
- Az Aura Displays hordozható monitorhármasa jól felturbózhatja a produktivitást
- Dual Mode-os IPS monitorral adott magáról életjelet a Gigabyte
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen széket vegyek?
- Sony MILC fényképezőgépcsalád
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- Azonnali fotós kérdések órája
- Milyen billentyűzetet vegyek?
- Apple MacBook
- Milyen házat vegyek?
- Azonnali alaplapos kérdések órája
Új hozzászólás Aktív témák
-
jetarko
csendes tag
Van egy osztályom aminek az adattagjait validálom, hibernate validator segítségével.
A következő a problémám:
Van az osztályban 10 db adattag és mindre van feltétel.
Amikor teljesen új objektumot veszek fel bejön 10 adat és a validáció remekül megtörténik.
A többi esetben mondjuk csak 5 adattagot akarok módosítani, de a másik 5 adattagot nem akarom előtte megosztani(pl form-ba rakni,se hidden mezőbe rakni). Ekkor bejön 5 adattag amik lehet, hogy megfelelnek,de a többi 5 miatt elbukik a validáció, mert azok üresek maradnak.
Erre a megoldás, hogy létrehozok olyan osztályokat ami csak ezt az 5 adattagot tartalmazza és majd az eredeti objektum ezen 5 tagját módosítom vagy megadok előtte minden adattagot, ami nyilván nem a legjobb módszer.
Jelenleg a problémámhoz elég lenne 2 db ilyen osztályt csinálnom és valószínűleg nem is lenne több eset, de mi lenne ha ez már 30 db különböző osztály? Az összes osztályban ugyanaz a logika, csak más adattagok vannak benne.
Erre vmi értelme megoldás van?
Pl gondolok itt olyanra, hogy mikor jön be az adat Spring controllerben, akkor a @Valid annotációban vhogy felsorolnám, hogy melyik adattagokat validálja vagy erre saját Validatort kell írni? Nem próbáltam, de ahogy nézem ha manuálisan hívom meg a validatort, akkor lehet állítani, hogy melyik mezőkre történjen tényleges validáció, valami ilyesmit szeretnék. -
#7297
bucsupeti
senior tag
WonderCSabo
#7296
bucsupeti
senior tag
válasz
WonderCSabo
#7296
üzenetére
windowsokon nem tudom most éppen mi a működés, de linuxon szerintem is az üres sorok kiiratása a jó módszer. -
#7296
WonderCSabo
félisten
Aethelstone
#7294
WonderCSabo
félisten
válasz
Aethelstone
#7294
üzenetére
Ez mondjuk az IDE consoljára nem biztos, hogy hatássas lesz. Rondábbnak tűnő, de platformfüggetlen megoldás jó sok új sort kiírni.
norbert1998: Ha System.err -re írsz System.out helyett azt remélhetőleg pirossal írja.
-
#7295
norbert1998
nagyúr
Aethelstone
#7294
norbert1998
nagyúr
válasz
Aethelstone
#7294
üzenetére
Köszi, holnap megnézem
-
#7294
Aethelstone
addikt
norbert1998
#7293
Aethelstone
addikt
válasz
norbert1998
#7293
üzenetére
if os == windows {
Runtime.getRuntime.exec("cls");
} else if os == *nix {
Runtime.getRuntime.exec("clear");
} else {
Runtime.getRuntime.exec("akármi, ami konzolt töröl....");
}Amolyan pszeudóféleképpen
-
#7293
norbert1998
nagyúr
Sk8erPeter
#7292
norbert1998
nagyúr
válasz
Sk8erPeter
#7292
üzenetére
Olyanra gondoltam, amit a programkódba lehet írni, de akkor gondolom ilyen nincs. Mindegy, köszönöm
Olyan van esetleg, hogy amit oda kiír a NetBeans, azt vastgított vagy dőlt vagy valamilyen kiemelt betűvel tegye egy-egy sornál?
-
#7292
Sk8erPeter
nagyúr
norbert1998
#7291
Sk8erPeter
nagyúr
válasz
norbert1998
#7291
üzenetére
Jobb gomb az Output ablakban, majd Clear, vagy nyomatsz egy Ctrl+L-t...
-
#7291
norbert1998
nagyúr
Sk8erPeter
#7290
norbert1998
nagyúr
válasz
Sk8erPeter
#7290
üzenetére
Bocsánat. NetBeans IDE
-
#7290
Sk8erPeter
nagyúr
norbert1998
#7289
Sk8erPeter
nagyúr
válasz
norbert1998
#7289
üzenetére
A konzol/terminál tartalmát szeretnéd törölni? Mert Windows-on az a cls bepötyögésével, majd Enterrel megoldható, Linuxnál a clear kulcsszóval.
(Már ha jól értettem a kérdésedet...)Hogy kell elképzelni ezt, hogy mindent konzolon csináltok? nano, mcedit (most ezek Linux-eszközök, de mindegy), vim (bár ezt kétlem), ilyesmik használatával szerkesztitek a kódot?
(#7288) floatr:
A Java-fejlesztőknek nem a hosszú távú támogatás jár a fejében? Ez így furán hangzik.
-
#7289
norbert1998
nagyúr
norbert1998
nagyúr
Lenne még egy kérdésem. Mivel grafikusan még nem programozunk, hanem mindent konzolon csinálunk, így egy idő után cseszett bonyolítottá válik a konzol. Lehet valamivel olyasmit csinálni, hogy a konzol tartalmát töröljük?
Egy hierarchikus switch-case menürendszerről lenne szó, összesen 22 választható elemmel, egymásba szinteződve, javarészt. -
#7288
floatr
veterán
Sk8erPeter
#7286
floatr
veterán
válasz
Sk8erPeter
#7286
üzenetére
Sajnos láttam már miket műveltek a forrásban
Látszik hogy nagy code wariorok voltak a szerzők, de nem is a hosszútávú támogatás járt a fejükben, amikor megszülték a művüket. De ez elmondható elég sok frameworkről is. -
#7287
WonderCSabo
félisten
floatr
#7283
WonderCSabo
félisten
Offensive programming nem is olyan hülyeség.
-
#7286
Sk8erPeter
nagyúr
floatr
#7281
Sk8erPeter
nagyúr
Szerintem tanulmányozd magának a Javának a forráskódját, rá fogsz csodálkozni, hogy TELE van a break kulcsszó használatával ciklusokon innen és túl is.
Na nem mintha azt akarnám sugallni, hogy az biztos a világ legjobb kódjainak gyűjteménye, de valószínűsíthetően nem kókler kretének írják, akik azért használnak breaket, mert buták, és nem tudnak kódolni. -
floatr
veterán
Hát néha a klingonos sem az. Nemrég fordult elő, hogy valaki addig kavart az SVN branch-ekkel, hogy olyan is LIVE-ba ment, aminek nem kellett volna. Szó szerint nem release volt, de még csak nem is szabadjára engedték, hanem megszökött. A QA csoport véres hullái rész meg csak azért maradt el, mert mire fizikailag odaért volna a PO, addigra lecsillapodott
-
#7283
floatr
veterán
Aethelstone
#7282
floatr
veterán
válasz
Aethelstone
#7282
üzenetére
Bár nem mai, de ha már igazi programozó: [link]
-
#7281
floatr
veterán
Sk8erPeter
#7277
floatr
veterán
válasz
Sk8erPeter
#7277
üzenetére
Bár emiatt mondtam, hogy megoldás kérdése, elsőre lehet h vacakul hangzik, de ha jön egy break-es megoldás, könnyen jöhet egy későbbi CR, aztán jön a többi break is. Ha az első beteszi a lábát a ciklusba, akkor megette a fene, én átírom inkább valami iterátoros cuccra, sakko lesz feltételed.
De nem akartam kötekedni, csak megjegyeztem, hogy a break rontja a kódot.
szerk: olyanok ezek a dolgok, mint a petárda. Kicsit pukkangatnak, sokan nem értik, aztán egyszer leviszi a kezed.
-
#7280
norbert1998
nagyúr
Sk8erPeter
#7279
norbert1998
nagyúr
válasz
Sk8erPeter
#7279
üzenetére
Gondolom, én is, bár most hallottam róla először.
-
#7279
Sk8erPeter
nagyúr
norbert1998
#7278
Sk8erPeter
nagyúr
válasz
norbert1998
#7278
üzenetére
Teljesen érthető for-ciklusnál, de én még mindig foreach-ről beszélek, gondolom majd azt is fogjátok tanulni.
-
#7278
norbert1998
nagyúr
WonderCSabo
#7269
norbert1998
nagyúr
válasz
WonderCSabo
#7269
üzenetére
Ugyanazt javasolta, mint ti. Extra. Console. Readint. [és ezt rendesen formázva, csak buta a t9]
Sk8erPeter: azért kéri így, hogy megtanuljuk a for, while és do-while ciklusokat használni.
Tényleg lehet break-kel kocolni, alairom, csak az adott esetben teljesen működőképes volt.
Köszönöm a segítséget
-
#7277
Sk8erPeter
nagyúr
floatr
#7275
Sk8erPeter
nagyúr
"Én inkább vagyok híve egy olyan megoldásnak, ahol inkább a ciklus feltételeinek kiértékelésénél próbálod megoldani a kilépést."
Nem véletlenül mondtam az előbb a foreach-ciklust, még ki is hangsúlyoztam, hogy nem sima for ciklusról van szó. Magyarul nincs ciklusfeltétel, kész. Cserébe magának a ciklusnak a "fejléce" szebb tud lenni, nincs szükség indexelésre, és így tovább, hát ugye a foreach-ciklus szépsége. Berakva egy if(...) { break; }-et (nyilván szépen tördelve) semmivel sem lesz rondább, ha az nem valahol egy túl nagyra hízott ciklustörzs (eleve már itt kezdődik a gond) közepén helyezkedik el valahol, teljesen egyértelmű a ciklus megszakítása, szóval nem igazán tudom felfogni, nálad miért nem menne át a kódreview-n. Erre mondtam, hogy sokszor nevetségesek ezek a teljesen rugalmatlan "szabályok". Vannak általános irányelvek, amiktől rondább vagy szebb lesz egy kód, de általánosítani itt is tök felesleges. Sima for ciklusnál teljesen érthető, egy foreach-nél nem, nem lesz tőle rondább a kód, ha a kódot olvasó emberke számára nem egyértelmű, hogy ott bizony valamitől függően kilépés lesz a ciklusból, hát akkor nem a kód írójával van baj. -
#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.
-
#7275
floatr
veterán
Aethelstone
#7272
floatr
veterán
válasz
Aethelstone
#7272
üzenetére
Én inkább vagyok híve egy olyan megoldásnak, ahol inkább a ciklus feltételeinek kiértékelésénél próbálod megoldani a kilépést. Nyilván lesz olyan eset, amikor nagyon nyakatekert lenne break nélkül, de sokszor csak rontja a support-ot.
-
#7274
Aethelstone
addikt
Oppenheimer
#7273
Aethelstone
addikt
válasz
Oppenheimer
#7273
üzenetére
A label már durva, de egy breakkel semmi baj. Nyilván célszerűbb valami do while vagy while szerkezetet felépíteni, ha az ember ki akar idő előtt lépni, de szerintem a for loop-ban elkövetett breakkel sincs semmi baj. Ha az ember módjával használja. Persze háromezer if the else és switch szerkezetekben 678 break nem szép....
-
#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.
-
#7271
floatr
veterán
norbert1998
#7268
floatr
veterán
válasz
norbert1998
#7268
üzenetére
A wildcard-os import egyszerűen bad practice. Néha gyorsabb megoldani valamit vele, de a mai IDE-k támogatják az import sorok generálását is; beírsz valamit, aztán vagy magától megtalálja, hogy mit kell beszúrni, vagy rákérdez, hogy melyiket a sok közül szeretnéd.
Viszont a break-es témában igaza volt, hogy azzal össze lehet kócolni a kódot rendesen.
(#7270) Sk8erPeter háááát... nálam a kódreview-n nem menne át
-
#7270
Sk8erPeter
nagyúr
norbert1998
#7268
Sk8erPeter
nagyúr
válasz
norbert1998
#7268
üzenetére
Remélem, azért nem szól be, ha egy foreach-ciklusnál (nem sima for) adott esetben használsz breaket... néha vannak emberkék, akik kitalálnak ilyen "szabályokat", hogy legyen mivel lefoglalni magukat.
A kód olvashatóságát pedig ez például nem rontja. -
#7269
WonderCSabo
félisten
norbert1998
#7268
WonderCSabo
félisten
válasz
norbert1998
#7268
üzenetére
Akkor ha bármilyen negatív dolog lenne ezzel kapcsolatban.
-
#7268
norbert1998
nagyúr
WonderCSabo
#7265
norbert1998
nagyúr
válasz
WonderCSabo
#7265
üzenetére
Levonni nem hiszem, hogy levonnak. Mikor tz-be while helyett for ciklust tettem if-es break-el,annyit mondott, hogy te [legyen a vezeteknevem mondjuk] kovács! Megmondtam, hogy órán ne breakelj. Most nézzétek meg, ti itt dolgozatot írtok, ez meg itt breakel...
Egyszóval, nem fog érte megölni, jo fej ürge. De mindjárt beérek, megkérdezem tőle.
-
#7265
WonderCSabo
félisten
norbert1998
#7261
WonderCSabo
félisten
válasz
norbert1998
#7261
üzenetére
Ne viccelj, ha emiatt levonnak a megoldásodból, akkor hagyd ott azt az intézményt...
-
#7264
Ursache
senior tag
norbert1998
#7263
Ursache
senior tag
válasz
norbert1998
#7263
üzenetére
Igen.
-
#7262
Ursache
senior tag
norbert1998
#7261
Ursache
senior tag
válasz
norbert1998
#7261
üzenetére
Igen.
-
#7260
WonderCSabo
félisten
norbert1998
#7258
WonderCSabo
félisten
válasz
norbert1998
#7258
üzenetére
Én egyáltalán nem javaslom a wildcard (*) importokat, pont az ilyen gondok miatt. Csak azokat az osztályokat importáld, amiket ténylegesen használsz, ne egész csomagokat. [link]
-
#7259
Ursache
senior tag
norbert1998
#7258
Ursache
senior tag
válasz
norbert1998
#7258
üzenetére
Egyszerűen ne importáld az egyik packaget, hanem amikor hivatkozni szeretnél rá, akkor a teljes (minősített [fully qualified package name]) nevét használd.
Pl.: extra.Console.etc
-
#7258
norbert1998
nagyúr
norbert1998
nagyúr
Üdv!
Lenne egy kis gondom. Beadandót kell csinálnunk java-bol, de adódott egy elég nagy gondom rögtön az első soroknál.
Mi bevitelhez az extra.Console-t használjuk, viszont kellene a FileWriter is abba a programba, meg úgy eléggé sokminden a java.io-ból is. Úgy rémlik, ezzel semmi gond nem volt, mintha még írtunk is volna ilyen kis programot a suliban, de nekem nem megy.
Beírom, ahova szokás, hogy
import java.io.*;
import extra.*;
És amikor az első sorba belekezdenék:
int fomenu=Console.readInt("blablabla");
Fogja magát, és kiirja, hogy ütközés van a java.io.* és az extra.* között, mert mindkettőben van Console osztály.
Mit lehet tenni ezellen?Osztálytársaknak is mind működik, hiszen, van, aki már be is fejezte a programját, és ennek a két dolognak benne kell lennie.
-
http://blog.jamesdbloom.com/JVMInternals.html
Erdemes lehet atfutni.
-
#7256
WonderCSabo
félisten
szcsaba1994
#7255
WonderCSabo
félisten
válasz
szcsaba1994
#7255
üzenetére
Oké, de akkor mit vársz tőlünk? Mert a kód alapján többet nem tudunk mondani.
-
szcsaba1994
tag
válasz
WonderCSabo
#7254
üzenetére
A tömb eleme null, ezt már kiderítettem
-
#7254
WonderCSabo
félisten
szcsaba1994
#7253
WonderCSabo
félisten
válasz
szcsaba1994
#7253
üzenetére
Mivel nem osztottad meg az egész kódot, ezért a kövi lehet:
maga a tömb eleme null VAGY
a rand változó nullEzt egy másodperc alatt ki lehet deríteni debuggerrel.
-
szcsaba1994
tag
válasz
szcsaba1994
#7252
üzenetére
Ez lemaradt, még előtte van:
Karakter[] elsoJatekos = new Karakter[karakterSzam * 2];
Karakter[] masodikJatekos = new Karakter[karakterSzam * 2];
int karakterSzam = 0, karValEgy = 0, karValKetto = 0; -
#7251
Ursache
senior tag
szcsaba1994
#7250
Ursache
senior tag
válasz
szcsaba1994
#7250
üzenetére
Ott nincs inicializálva a tömb. Bár mondjuk ez elég kevés kód, pastebinre töltsd fel.
-
#7250
szcsaba1994
tag
szcsaba1994
tag
Sziasztok!
Van egy file, aminek a tartalma egy szó(objektum típusa), utána pedig 4 attribútum, amik az objektum konstruktorába kerülnek.
Ebből a file-ból szertnék beolvasni, gyakorlatilag eg játékállást betöltve.
Ha az elején 2-es gombot nyomom le, akkor olvassa be a fájból, ha az egyest akkor teljesne új játékot kell kezdeni (ez gond nélül meg is van)Kb így néz ki:
Tipus[] tombEgy;
Tipus[] tombKetto;
if(gomb==2){
betoltes(tombEgy, fileEgy);
betoltes(tombKetto, fileKetto);
}
if(gomb==1){
tombEgy = new Tipus[db];
tombKetto = new Tipus[db];
feltolt(tombEgy);
feltolt(tombKetto);
}Mikor a betöltöttel szeretnék játszani, kapok egy NullPointerExceptiont akkor, amikor a tombKetto-t használnám először
Mi lehet a gond?
-
#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.
-
#7248
floatr
veterán
Oppenheimer
#7247
floatr
veterán
válasz
Oppenheimer
#7247
üzenetére
lyaly
Itt azért elkövettél pár olyan dolgot, amivel alá lehet vágni egy kitervelt rendszernek. Egyrészt - bár ismétlem magam - ez a generált kód... szerintem jobban jársz, ha egy kicsit veszed a fáradtságot, és megtanulod magad legyártani a kódot a táblák alapján, vagy fordítva.Ha már generáltál valamit adatbázis valami alapján, akkor nagyon észnél kell lenni, hogy mibe túrsz bele. Itt épp azzal babráltál, amivel nem kéne. Mellesleg nekem amiatt gyanús a metódusra akasztott annotációval, mert olyan, mintha félig, vagy egyáltalán nem értené, hogy máshogy akarod elnevezni. Ha már annotálod a cuccot, akkor az átláthatóságot is növeli, ha a mezőkre aggatod őket.
Az@Id mellé még odatenném a @GeneratedValue-t is, mert ezzel a legtöbb adatbázisnál tud auto increment-es típust használni.
-
#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 -
#7243
floatr
veterán
Oppenheimer
#7242
floatr
veterán
válasz
Oppenheimer
#7242
üzenetére
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. A helyedben én az @Id és @Column annotációkat nem a metódusokra tenném.
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.
Az org.hibernate.cfg.DefaultComponentSafeNamingStrategy nekem eddig minden problémámat megoldotta -
#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;
} -
#7241
Mukorka
addikt
Oppenheimer
#7240
Mukorka
addikt
válasz
Oppenheimer
#7240
üzenetére
Ha már mappeled az entitást akkor minek vannak ott az id-k pl a Movies2ActorsEntity-ban? Ez talán nem okoz problémát bár vicces lehet ha átállítod az entitást és az id meg marad a régi. (Gondolom felülírja az újal de lehet hogy nem).
MoviesEntity -ben hol a characters mappelése?
-
#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;
} -
#7239
emvy
félisten
Oppenheimer
#7238
válasz
Oppenheimer
#7238
üzenetére
A @ManyToOne (vagy hasonlo) attributum mellett megadod a @JoinColumn(name=genreId)-t is? Mert tippre az a helyzet, hogy a join soran generalja neked a genre_id oszlopnevet.
-
#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.
-
#7237
emvy
félisten
Oppenheimer
#7236
válasz
Oppenheimer
#7236
üzenetére
Nem arrol van szo, hogy ezt a tablat joinolod valami masik tablaval?
-
#7236
Oppenheimer
nagyúr
Oppenheimer
nagyúr
Ha már Hibernate. Ez WTF?
-
#7234
floatr
veterán
Aethelstone
#7232
floatr
veterán
válasz
Aethelstone
#7232
üzenetére
Amit eddig láttam, az alapján azt tudom mondani, hogy amint a projekt megéri a telepítési fázist kiderül, hogy bármilyen generált kódról is van szó, a fejlesztők csak becsapják magukat, hogy majd sokkal kevesebbet kell kódolni. Hihetetlenül észnél kell lenni, mert elég egy legyintés, hogy ez így majdnem jó, és oda minden előnye a generált cuccoknak. Ezt a legtöbben nem is látják, mert valamiért nem foglalkoznak a release utáni életciklussal. Ugyanez igaz a DTO-ra is, hogy leszámítva azt az 1%-ot, amikor tényleg kellene, csak felesleges karbantartási köröket, és kockázati tényezőt vezetnek be a projektbe. Az ember hajlamos elsiklani olyan problémák felett, amiket nem lát rögtön, mert kényelmes nem szembesülni vele.
Hibernate-tel már odáig jutottunk, hogy az összes előnye leredukálódott a bean alapú row mappingre, és az öröklődés kezelésére. Nem 1% az, amit kézimunkával kell megoldani, de erről már a múltkor beszéltünk a lazy-eager-dto témában.
Nálunk a legtöbb szívás a GWT-vel a frontend hibái miatt voltak. Még csak nem is a generált kód és a backend közti szakadék miatt. A frontendesek annyira sokat dolgoztak a minimális hibákon, hogy a végeredmény az lett, hogy vagy sikerült megalkudni a megrendelővel, vagy addig hegesztették böngészőnként a dolgot, hogy az összköltsége elszaladt egy bootstrap/foundation alapokra épülő jquery/sencha kliens + SOA backend mellett. Sajnos vagy sem, de eddig mindig ide lyukadtunk ki, akármi is volt a kiindulási alap.
-
#7233
Aethelstone
addikt
floatr
#7230
Aethelstone
addikt
Ilyen dolgokkal már sokszor találkoztunk, hogy jó valami, de senki nem tudja használni.
Ez nem igaz. Jó és sokan jól tudják használni, viszont sajnos azok hangosabbak ("micsoda fos ez a gwt") és társai, akik nem tudják használni. Eklatáns példa az ismerettségi körből. Aki ért hozzá, az tudja, hogy bűncselekmény egy-egy GWT-s framework használata, főleg azok, amik csak JS wrapperek (SmartGWT pl.). Azt kezdi el használni és utána csalódottan hagyja az egészet a francba, mert hogy micsoda fos ez..közben meg a standard GWT-vel sokkal jobb eredményei lennének. Vagy egészen egyszerűen nem tudják az MVP-t használni, ami pedig a GWT-t fejlesztés alfája-omegája......és lehetne sorolni, de nem csak GWT-s, hanem egyéb fronton is.
-
#7232
Aethelstone
addikt
floatr
#7229
Aethelstone
addikt
Jó, a generált kód nyilván nem az elérhető legjobb, viszont megvan az az előnye, hogy a minősége(legyen az bármilyen) állandó.
És ha most maradunk a GWT-nél, akkor ki lehet mondani, hogy sokkal jobb a generált JS kód minősége, mint amilyet bármelyik csak Java-s, de még gyakorlott JS fejlesztő is tudna gyártani "kézzel".
És ne felejtsük el azt sem, ha már a Spring/Hibernate és egyebek szóba kerültek, hogy ezek a generált szarok az esetek 99%-ban megfelelő minőségűek az adott feladathoz. A maradék 1%-ban meg jössz Te és implementálod az ultimate kódot
-
#7230
floatr
veterán
Aethelstone
#7228
floatr
veterán
válasz
Aethelstone
#7228
üzenetére
Hát, bárhogy is nézzük a végeredmény ugyanaz, hogy kevesen tudnak jól bánni vele (már he lehet ilyenről beszélni
)Ilyen dolgokkal már sokszor találkoztunk, hogy jó valami, de senki nem tudja használni. Ergo, akkor mégsem annyira jó valami. Lehet h túl komplex, túl nagy a betanulási igénye, akármi... Arról mindenesetre meg vagyok győződve, hogy egy olyan team, ahol megfelelően le vannak osztva a szerepkörök, hatékonyabb tud lenni egy csak javas GWT-s csapatnál, ahol könnyen becsapják magukat az emberek, hogy nem kell frontendes.
-
floatr
veterán
Bizonyos fokig a compiler is átver. Még az elmúlt évezredben volt egy olyan hardveres problémája az x86-os prociknak, amikor bejött a pipeline, hogy bizonyos kódegyüttállás esetén az egymást követő utasításokat x lépésen belül egyszerűen nem tudta feldolgozni. Ezt a legtöbb C fordító korrigálta úgy, hogy te nem tudtál róla. Ez a pozitív része az átverésnek, ha jól csinálta. Volt azonban olyan C fordító, ami úgy optimalizálta a fordított kódot, hogy éppen belefutott ebbe a pipeline/cache hibába.
Itt viszont egyik nyelvről a másikra generál egy kódot, amit egy framework keresztimplementáció igyekszik elfedni. A dolog már ott sántít, hogy eltérő implementációkról van szó.
A hibernate/JPA által generált SQL-re inkább nem mondok semmit. Nem véletlen, hogy nagyon kevés a jó HQL/JPQL szakember, mint ahogy az sem, hogy a kritikus query-k mind natív SQL-ben készülnek, vagy tárolt eljárásban. Amit meg a proxy-kkal, ASM/CGLIB meg egyéb témával generálnak, az nem ugyanaz a nagyságrend, amivel egy Java-JS fordításnál szembesülsz.
(#7227) Aethelstone Ja hogy a parse-oláshoz beaneket, milyen igaz. Úgy szar ahogy van
)
Kézzel jobbat gyártottam, és ráadásul tudtam, hol kell a sallangot kicsapni.
De mondhatnád a spring boot-ot is, a hibernate entitás/schema generátorát, meg ilyenek. Nem akarom elvinni a témát a nagyzolás irányába, de ezeket ha tehetem kerülöm, mint a pestisest. Még talán a schema generátor elmegy, de azon is sokat kell utólag szöszölni, mire összeáll úgy, ahogy szeretném, mert nem lehet eléggé teletűzdelni metaadatokkal, hogy mindent normálisan megcsináljon. Sajnizom, hogy rossz véleményem van róla -
Ezzel altalanossagban nem ertek egyet. Ha nagyon tavolrol nezed, akkor a javac meg kesobb a JVM is kodot general, a legmagasabb (Java) absztrakcios szintrol kezdve vegig a gepi kodig. Az, ha ennek a tetejere meg raksz valamit, alapvetoen nem rontja el a dolgot. Arra nyilvan figyelni kell, hogy az absztrakciok sose tokeletesek, de ez siman lehet elfogadhato kompromisszum. A Hibernate is kodot general, peldaul.
-
#7225
floatr
veterán
Aethelstone
#7224
floatr
veterán
válasz
Aethelstone
#7224
üzenetére
Figy, én eddig azt láttam, hogy valaki vagy az egyikhez ért, vagy a másikhoz. Az már fehér holló kategória, aki valamennyire konyít mindkettőhöz, és ez nem csak hazai jelenség. Irtózatosan híg a szakma, és nem biztos hogy csak a képzéssel van a baj (bár a kollégám, aki elég húzós tanfolyamokat tart, erről meg van győződve). A legtöbb gyíkarc meg sem érti, hogy mitől gurul az egész, vagy ha elcsípi, akkor menekül tőle, mert a JS nem elég tudományos. Erre mondom, hogy kliens oldali technológiát, csak arra megfelelő emberekkel szabad gyártani, és ezek az emberek nem feltétlenül kell h backendet is tudjanak gyártani. Ezek a hibrid megoldások olyanok, mint a 4 évszakos gumi.
Vagy használjanak jfx-et, az tudományosabbabb. (bár az is halódik elfelé)
Szerk.: amit generálásképpen említettél, az metaadatokat/leírókat generál, nem kódot.
-
#7224
Aethelstone
addikt
floatr
#7221
Aethelstone
addikt
Ez nem igaz. Nincs semmi baj a kódgenerálással. Azzal van baj, ha a fejlesztőnek halvány fingja nincs, hogy mi generálódik. Nem kell pontosan tudni, de nem árt, ha mondjuk azt tudja, hogy JS lesz és böngészőben fog futni.
Engem(és másokat, akik akítvan GWT-znek) érdekes módon nem ver át....elején megtette, de az RTFM sokat tud segíteni. Sok más dolog van ami generál. xsd pl.És különben is, ha valaki nagyon kíváncsi, hogy mi generálódik, meg tudja nézni. Ott van feketén fehéren a JS forrás. Jah, hogy érteni kellene egy picit hozzá? Ez egy ilyen binisz
-
#7222
M_AND_Ms
veterán
Aethelstone
#7220
M_AND_Ms
veterán
válasz
Aethelstone
#7220
üzenetére
"pagert"? Mármint egy lapozós listát? Laponként 4-5K rekorddal?
Mert ugye a lapozósnak pont az a lényege, hogy a 4-5K rekordból mindig csak mondjuk 50-et jelenít meg. Az meg nem egy mennyiség -
#7221
floatr
veterán
Aethelstone
#7218
floatr
veterán
válasz
Aethelstone
#7218
üzenetére
Ezért mondom h dead end. Csak olyan frameworknek van értelme, ami nem új kódot generál, egyébként átveri a saját fejlesztőit is, mert kiveszi a kezükből a kontrollt.
-
#7219
M_AND_Ms
veterán
Aethelstone
#7218
M_AND_Ms
veterán
válasz
Aethelstone
#7218
üzenetére
Máris megkérdem, mi értelme van 4-5K rekordot kirakni a képernyőre. Ki az aki azzal bármit is kezd? Görgeti fel-s-alá, mást nem nagyon tud vele kezdeni.
-
#7218
Aethelstone
addikt
floatr
#7217
Aethelstone
addikt
Szerintem nem dead end, de ez most nem ide tartozik.
A GWT-vel alapvetően egy baj van, a fejlesztők. Úgy reklámozzák, hogy nulla JS tudással, Java fejlesztői képességek birtokában bárki össze tud vele kókányolni egy webalkalmazást. Aztán jön az egyszeri Java fejlesztő, finga nincs a css-ről, a div-ről meg általában a böngészős normákról és csodálkozik, hogy le akar fetchelni a szerverről 4-5K rekordot és ki akarja csapni a képernyőre....aztán a böngésző lefexik....és sorolhatnám...nem tudják használni. Teljesen nem veszik figyelembe, hogy a vége generált JS kód lesz...sírnak, hogy miért nincs reflection meg ilyesmi...
-
#7217
floatr
veterán
Aethelstone
#7215
floatr
veterán
válasz
Aethelstone
#7215
üzenetére
Szerintem a GWT-t is hozzáadhatod a dead end kategóriához
Sok technológiával volt már dolgom, de az ügyviteli felhasználásnál, és az újabb fajta webes alkalmazásoknál a SOA-jellegű backend + "natívan" fejlesztett erős kliens volt a leghatékonyabb. Az csak plusz, ha a kliens oldal olyan framework-ökre épít, amivel napok alatt lefejleszted azt, amihez MVC-vel hónapok munkája kellett.
(#7216) Oppenheimer Ha valami beadandó cuccról/szakdolgozatról van szó, akkor én nem erőltetném a finomságokat
Nekem sem tudták értékelni, amikor én agyaltam rajta. Diplomamunkaként egy GIS alapú facility management megvalósíthatósági tanulmányt adtam le, ami még ráadásul az egyetem munkáját is megkönnyítette volna, és egy rakat diákot rá lehetett volna robbantani a témára szervezetten, mire a vizsgabiztos csak annyit kérdezett, hogy mi ez az egész -
#7215
Aethelstone
addikt
floatr
#7214
Aethelstone
addikt
Az MVC önmagában egy elavult szar szerintem....ahogy írod is, a felesleges oldalletöltések miatt. Nekünk van még pár MVC-s projektünk, de kimerülnek már a default oldal letöltésében. Minden egyéb forgalom ajax/json kombóval megy.
A DTO-s okosságnak ott van egyébként értelme, ahol az entitásból kinyerhető adatok és a struktúrájuk valamiért köszönőviszonyban sincs azzal, amit a kliensre le kell zavarni(láttam már ilyet)...másrészről nekem sok GWT-s projektem volt és ott sokáig a DTO design patternt erőltették. Mostanában nem tudom, hogy miként van...2.4-nél leakadtam..
-
#7214
floatr
veterán
Oppenheimer
#7202
floatr
veterán
válasz
Oppenheimer
#7202
üzenetére
A JSON generálásra céloztam. És így van, ha adatokat adsz-veszel, akkor több kommunikációval jár, ami hálózati probléma lehet.
Másik oldalról viszont ott van a fejlesztés és karbantartás. A Java legnagyobb előnye az előtte lévő nyelvekkel/rendszerekkel szemben, hogy gyorsan tudsz eredményt produkálni, pláne ha ilyen irgalmatlan nagy ökoszisztéma jár vele. Ha lábon lövöd magad egy olyan implementációval, amivel időt veszítesz, és rugalmatlanná teszed az alkalmazásodat, és mindezt a hálózati forgalom miatt aggódva, akkor pont a Java előnyeit áldozod be. Néha erre szükség van, amikor nagyon kritikus a teljesítmény egy adott vason, de nem minden áron.
Tegyük fel, hogy a kommunikáció régebbi MVC-szerű alapokra épül. Oldalak jönnek le sokszor feleslegesen, mire a teljes adatkészletet megkapod. Ha már valami ajaxos megoldást is használsz, akkor az overhead sokkal kisebb lesz; akkor bukik ki a leginkább, amikor egy eseményre több kérést kell lezavarnod. A teljesítmény a hálózat teljesítőképességén, és a protokollon is múlik. Ha viszont már websocket/STOMP klienst használsz, akkor megint eltűnik az overheadből egy elég nagy rész, mert a kapcsolat felépítésének a költsége nem terheli a további requesteket; gyakorlatilag eljutsz odáig, mintha egy ESB/JMS integrációs megoldást használnál, aminek a másik végén egy repository jellegű szolgáltatás ül.
Szóval ha engem kérdezel, csak magadat szívatod meg a DTO-kkal.
-
#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
-
#7211
Mukorka
addikt
Oppenheimer
#7210
Mukorka
addikt
válasz
Oppenheimer
#7210
üzenetére
Ez akkor lenne jó ha cserébe az entitásban nem is említenéd meg a kapcsolatokat, máskülönben ugyanúgy duplikálás.
-
#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.
-
> Láttam olyan helyet, ahol ennek a menedzselésére bevezették a kódgenerálást. Ott aztán már durva állapotok vannak, ha az ember ilyesmire kényszerül. Egy xtend leíróban legózhatod össze a java forráskódot töredékekből, ezzel többféle forrást is generálhatsz
Jaja, kozben meg egy sor mellett elmagyarazzak neked, hogy a tobbszoros orokles egyebkent rossz, mert ize. Pl. a tobbszoros orokles hianya valami, ami _allandoan_ problema (nekem). A masik meg az, h nem lehet rendesen monkey patchelni, de az kisebb problema. Kodgeneralast mi akkor csinaltunk, amikor .Net-ben meg Javaban is el kellett erni ugyanazok az entitasokat -- ott tenyleg az volt a legegyszerubb, hogy mittudomen, XML-ben leirod, h hogy nez ki az ojjektum, aztan kesz.
-
#7208
Szmeby
tag
Oppenheimer
#7207
Szmeby
tag
válasz
Oppenheimer
#7207
üzenetére
Az alapvető probléma az, hogy két helyen kell ugyanazt karbantartani. Amíg csak néhány entitásról van szó, oké, de amikor elkezd növekedni a számuk, és elkezdenek ezek változni is, akkor születnek újabb bogárkák.
Mert például valaki elfelejtette átvezetni a módosítását a másik osztályba, elfelejtődik, és később jönnek a hibák.
Röviden: a duplikált kód rossz.Ez persze nem jelenti azt, ne lehetnél vele boldog, csak érdemes jobb megoldás után kutatni.
Láttam olyan helyet, ahol ennek a menedzselésére bevezették a kódgenerálást. Ott aztán már durva állapotok vannak, ha az ember ilyesmire kényszerül. Egy xtend leíróban legózhatod össze a java forráskódot töredékekből, ezzel többféle forrást is generálhatsz, amit majd a compiler fordít, stbstb. Így xtend-ben kell egyszer megírni a cuccot és az akár 20 féle DTO-t is kigenerál neked. Vagy amennyit akarsz. Tiszta káosz. Cserébe viszont az xtend nehezebben olvasható. Vagy lehet, hogy csak szokni kell. Szerencsére nem sokáig kellett gyönyörködnöm benne.
-
Szmeby
tag
Jobban belegondolva a google is szereti halmozni a rest hívásokat. Jó, persze mögötte ott egy bazinagy elosztott rendszer.
Pl. gmail:
Listás nézetben csak az első x db mail látszik (sender, subject és esetleg a body eleje). Nem fogja lehúzni az összes email összes tartalmát. Sőt egy conversationbe belépve sem tölt le mindent, csak az elsőt meg az utolsót. Ha akarod olvasni a többit majd kattintasz és lehúzza azokat is.
Ez soksok apró hívás, mindig csak a legszükségesebbet letöltve. Így fenn tudja tartani a látszatot, hogy ő milyen gyors. Szóval lehet ezt hatékonyan csinálni, csak meg kell találni az egyensúlyt.Megjegyzem, a konvertálgatást csak utolsó mentsvárként javasoltam.
-
#7205
Aethelstone
addikt
Oppenheimer
#7204
Aethelstone
addikt
válasz
Oppenheimer
#7204
üzenetére
Biztos, hogy majd kell. Szerintem a legjo bb ilyesmi tool.
-
#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. -
#7203
Aethelstone
addikt
Aethelstone
addikt
Alternatív megoldásként az entitások xstream annotációkkal ellátása jöhet szóba még. Lightweight és köthető entitásra vagy akár DTO-ra, Bean-re vagy akármire
Függően attól, hogy okoz-e hidegrázást a DTO konverzió, mégha automatikus is -
#7201
Mukorka
addikt
Oppenheimer
#7200
Mukorka
addikt
válasz
Oppenheimer
#7200
üzenetére
Szerintem arra gondolt hogy nem mappeli fel őket. Tehát a hibernate nem managelné a listát.
DTO konvertálás szerintem is csúfságos.
A kód olvashatóságát pedig ez például nem rontja.
)
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Bittorrent topik
- bitpork: MOD Júni 13 Augusztus 2- szombat jelen állás szerint.
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen széket vegyek?
- Mobil flották
- Sony MILC fényképezőgépcsalád
- Óra topik
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Kerékpársportok
- Fotók, videók mobillal
- További aktív témák...
- iKing.Hu - Samsung S25 Ultra - Titanium Black - Használt, karcmentes
- Apple Ipad 10.generáció
- Új HP Pavilion x360 14-ek Érintős hajtogatós Laptop Tab 14" -35% i5-1335U 8/512 FHD IPS Iris Xe
- RTX 4080 SUPER,16GB. Ryzen 7 7800X3D, 32 RAM Fury RGB! Garancia!
- Asztali PC , i7 9700K , RX 5700 XT , 32GB DDR4 , 500GB NVME , 1TB HDD
- REFURBISHED - DELL Thunderbolt Dock WD19TBS docking station (210-AZBV)
- DELL PowerEdge R740 rack szerver - 2xGold 6130 (16c/32t, 2.1/3.7GHz), 64GB RAM, 10Gbit HBA330, áfás
- ÁRGARANCIA! Épített KomPhone Ryzen 5 5600X 16/32/64GB RAM RX 7600 8GB GAMER PC termékbeszámítással
- Telenor 5G Indoor WiFi Router (FA7550) + töltő (bolti áruk 100.000Ft)
- BESZÁMÍTÁS! ASUS TUF Z390-PLUS GAMING alaplap garanciával hibátlan működéssel
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged