- AMD K6-III, és minden ami RETRO - Oldschool tuning
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Házimozi belépő szinten
- Milyen pendrive-ot vegyek?
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Gigabyte alaplap topik
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- LG C3: egy középkategóriás OLED tévé tesztje
- Milyen billentyűzetet vegyek?
- Fujifilm X
Új hozzászólás Aktív témák
-
#6929
WonderCSabo
félisten
Aethelstone
#6927
WonderCSabo
félisten
válasz
Aethelstone
#6927
üzenetére
Kivéve természetesen a primitív típusokat, azokat a generikusok nem támogatják
De szerencsére van autoboxing, emiatt ugyanúgy fog működni, ha primitíveket adsz át neki.
-
#6920
DNReNTi
őstag
Aethelstone
#6919
DNReNTi
őstag
válasz
Aethelstone
#6919
üzenetére
Hagyom így öt szálon, így is perfekt.
Köszi azért. -
#6917
DNReNTi
őstag
Aethelstone
#6916
DNReNTi
őstag
válasz
Aethelstone
#6916
üzenetére
No erre nem találtam rá, de megtaláltam rajta keresztül a megoldást. Kipróbáltam, most úgy tűnik működik, pár órára így hagyom, ha nem dől be akkor király. Köszi!
-
#6896
floatr
veterán
Aethelstone
#6894
floatr
veterán
válasz
Aethelstone
#6894
üzenetére
A jboss-deployment-structure.xml file-ban lehet definiálni, de talán van rá valami szabványos megoldás is a MANIFEST.INF-ben megadható dependency formájában.
Nem fogok most ennek utánajárni asszem, de én itt keresgélnék.
-
#6889
floatr
veterán
Aethelstone
#6882
floatr
veterán
válasz
Aethelstone
#6882
üzenetére
Akkor egy mongodb elég lesz alá. Vagy clusterben gondoltad?
-
#6881
floatr
veterán
Aethelstone
#6876
floatr
veterán
válasz
Aethelstone
#6876
üzenetére
Én első körben egy springet húznék alá, és a garázs management-et egy megfelelő perzisztenciával támogatott szolgáltatás végezné, a garázst elhagyó járműveket a fizetési felszólítás státuszba rakná, vagy archiválná
-
#6857
floatr
veterán
Aethelstone
#6856
floatr
veterán
válasz
Aethelstone
#6856
üzenetére
Szerintem az a gányolás, amikor összevissza kell konvertálgatni, hogy kiküszöböljük az egyik rétegben a másik rétegből adódó problémákat
-
#6855
floatr
veterán
Aethelstone
#6854
floatr
veterán
válasz
Aethelstone
#6854
üzenetére
Lehet h nem jött le, de szabályozott init-re gondoltam, nem AS módszer szerint.
Annyi felesleges kört futottunk már ezekkel a dolgokkal, és mindig csak magunkat szívattuk meg azzal, hogy még ezt is optimalizálni akartuk. Ha annyira teljesítménykritikus az alkalmazás, hogy nem bír kivárni egy connection-nel annyit, hogy a jsp legyártja az output-ot -- ugye lefordított classról beszélünk itt is, akár egy controller/service esetében -- akkor ott már nem ezen fog múlni a dolog, hanem már magán a perzisztencián és az adatbázison. A jsp nagyságrendileg hamarabb végez, mint amennyi ideig tart az adat előállítása.Ha most egymás után lerajzolgatod egy grafikonra, hogy mi mennyi ideig tartott: pl. entity lekérdezés, 2-3 külön init, beanmap/reflection alapú konverziók kontra entity, 1-2 init, rakat println meg még 1-2 init, akkor az esetek nagy részében azt fogod látni, hogy a grafikonon a 100%-ból elég kis szeletet harap ki a JSP, akárcsak a konverziók. Ismerek olyanokat, akik képesek nagyon lassú JSP-ket gyártani, de ez szerencsére a ritkábbik eset. Még a velocity/freemarker feldolgozás is lényegesen gyorsabb, mint az IP alapú adatműveletek.
-
#6850
Mukorka
addikt
Aethelstone
#6849
Mukorka
addikt
válasz
Aethelstone
#6849
üzenetére
Pont erre gondoltam pedig. Tehát azt hogy mi kell épp és mi nem csak különböző beanekkel tudod megoldani vagy már eleve úgy kérdezed le az entitást vagy mindig lekérdezel minden lazy tagot.
-
#6848
Mukorka
addikt
Aethelstone
#6841
Mukorka
addikt
válasz
Aethelstone
#6841
üzenetére
Hát nálunk a DAO és a business réteg egyben van. Minden logika ejb-ben van de konkrét crud műveletek nincsenek kiszervezve dao rétegbe hanem benne vannak a releváns ejb-ben.
A te példád szerint tehát ha van egy entitásom 5 lazy collection-el és 3 féle logika alapján dőlhet el hogy épp mit fetchelek fel akkor a service rétegedben 3 tök különböző (nyílván egymás leszármazottjai) dto osztályod lesz hogy a reflectionös cucc működjön? Ez elég gázul hangzik
(#6847):
Riporthoz írsz viewt amit felmappelsz és kész. nyílván ez globlális riportokhoz jó, ha sok az adat és bemenő paraméterrel kell dolgozni akkor valóban kell rendes sql-t írni.
-
#6841
Aethelstone
addikt
Aethelstone
#6840
Aethelstone
addikt
válasz
Aethelstone
#6840
üzenetére
Egyébként a Serialization policy is jó, de mi inkább azt az utat választottuk, hogy bean transzformálási szabályokkal korlátozunk. Egy kvázi automata eszközt használunk, ami reflectionnal megy végig és az azonos nevű tagokat transzformálja. Ami pedig nincs benne a Bean-ben vagy máshogy hívják, azt nem transzformálódik.
-
#6839
floatr
veterán
Aethelstone
#6836
floatr
veterán
válasz
Aethelstone
#6836
üzenetére
Magyarán DTO-t használsz két réteg közt a backenden. Nálam a review-n nem menne át
Mostanában legtöbbször SOA alapú rendszereket fejlesztünk, ahol web service-szerű cuccokig utazik az entitás. Ott a serialization-nel le van szabályozva, hogy mi mehet tovább. Szerintem bűn másodlagos, harmadlagos adatábrázolást ráhúzni egy működő struktúrára, ha van eszközöd normális módon kezelni a meglévőt, ráadásul épp ezzel csapod agyon az ORM-et, hogy a service-ig nem jut el a lényeg.
A teljesítményproblémákra azt tudom mondani, hogy persze hogy gyorsabb a háttérben egy SQL végrehajtása, mint többé (eager kontra lazy init), de csak mondom, hogy a hibernate/jpa önmagában egy nagy teljesítményprobléma.
A prezentációs réteggel kapcsolatban viszont nem értem mire gondolsz. Ha a kliens oldalra, akkor nyilván, de JSP-ben simán elfér egy implicit lazy init, amikor oda jut a sor.
-
#6837
Mukorka
addikt
Aethelstone
#6836
Mukorka
addikt
válasz
Aethelstone
#6836
üzenetére
Nem tetszem érteni amire gondolsz.
-
#6834
Mukorka
addikt
Aethelstone
#6833
Mukorka
addikt
válasz
Aethelstone
#6833
üzenetére
De ha már nincs session akkor hiába hivatkozik rá.
Nálunk egyébként lazy minden és ahol olyan eset van ahol kell valami ott van rá külön fv ami azt is betölti amit kell. -
#6814
_kovi_
aktív tag
Aethelstone
#6813
_kovi_
aktív tag
válasz
Aethelstone
#6813
üzenetére
Köszi!
Igen az utóbbira gondoltam én is, csak a megvalósításában még nem vagyok annyira perfekt.
-
#6798
floatr
veterán
Aethelstone
#6794
floatr
veterán
válasz
Aethelstone
#6794
üzenetére
in memoriam Donnie Brasco
(#6796) WonderCSabo random guglizással
http://mprabhat.com/2012/09/30/full-text-search-with-hibernate-search-4-1-lucene-and-jpa/De mysql natív query-vel is működhet a dolog. A LIKE meg csak akkor gáz, ha wildcarddal is kezdődik a kifejezés. De meg lehet oldani ezt úgy is, hogy pl elosztott nosql adatbázisban kérdezel körbe.
-
#6796
WonderCSabo
félisten
Aethelstone
#6795
WonderCSabo
félisten
válasz
Aethelstone
#6795
üzenetére
Azt egy szóval sem mondtam, hogy az IMDB LIKE-al működik, mert fogalmam sincs mivel működik. Az eredeti kérdés az volt, hogy lehet JPA-val megoldani, és LIKE-al meg lehet. Ha nincs túl sok sor, akkor jó lesz, ha nem, akkor nyilván lassú. MySQL-ben pl. van full text search, azzal meg lehet gyorsítani a dolgokat, pont erre való. Nem tudom, JPA-ra hogyan lehetne áthozni a featuret.
A leggyorsabb megoldás persze egy suffix fa építése lenne a memóriában, ahol minden node az adatbázis egy sorára is mutat. Persze ehhez sok adat esetén nagy memória kell.(#6794) Aethelstone: Jajj.
-
#6730
M_AND_Ms
veterán
Aethelstone
#6729
M_AND_Ms
veterán
válasz
Aethelstone
#6729
üzenetére
Arról volt szó, hogy legalább az alap kell.
Azért, egy általános api doksi nem túl bonyolult nyelvtanilag: egyszerű jelen, múlt, jövő. A függő beszéd elég ritka. Mindez egy kis szótárazással (Google) szépen megérthető. No meg egy adag akarás is szükséges.Sohasem tanultam németet. Anno, 12 évesen első lépéseimet a basic-ben a Texas Intsruments 99/4A géphez adott német doksi és egy német szótár alapján tettem meg. Csak akarni kellett, nem pedig megadni magam és segítségért kiáltani.
-
#6704
kornyiktamas
aktív tag
Aethelstone
#6703
kornyiktamas
aktív tag
válasz
Aethelstone
#6703
üzenetére
hát igen kb ezt értem is én, de hogy mit mivel milyen függvénnyel kell megoldani azt már nem tudom.. tehát azt se tanultuk, hogy hogy kell megadni a string hosszát hogy mekkorát írhat be...
-
#6701
fatal`
titán
Aethelstone
#6700
fatal`
titán
válasz
Aethelstone
#6700
üzenetére
Pontosan erre céloztam, hogy szerintem itt senki nem fogja megírni helyettük. Illetve van az a pénz
De én pl. még akkor sem, mert nincs rá időm Ha valahol elakadtak és segítséget kérnek, az teljesen más.
Az IDE / nyelv és egyéb dolgokba nem akartam belekötni.
-
#6638
tick
aktív tag
Aethelstone
#6637
tick
aktív tag
válasz
Aethelstone
#6637
üzenetére
Köszönöm az infokat
-
#6627
jetarko
csendes tag
Aethelstone
#6626
jetarko
csendes tag
válasz
Aethelstone
#6626
üzenetére
És ha kihagynám a template engine részt, és helyette beüzemelném az Angular js-t? Mondjuk fogalmam nincs, hogy mikor melyik megoldást érdemes használni. Erről tudsz valamit mondani?
-
#6620
floatr
veterán
Aethelstone
#6619
floatr
veterán
válasz
Aethelstone
#6619
üzenetére
Höhö, indítsunk mozgalmat...
-
#6618
floatr
veterán
Aethelstone
#6615
floatr
veterán
válasz
Aethelstone
#6615
üzenetére
Nekem a generics példányoknál nem fáj az, hogy nincsen runtime generált osztály. Ami fáj, az az öröklési elvek sérülése, ami megint ilyen fordító hekkelés miatt van, mint amit a múltkor bedobtam az enumokkal, konstansokkal kapcsolatban. A nyakát szegik a nyelvnek.
-
#6616
WonderCSabo
félisten
Aethelstone
#6615
WonderCSabo
félisten
válasz
Aethelstone
#6615
üzenetére
Ugye itt generic collectionről van szó, az instanceof itt csak a taroló típusban segít, az elemek típusában már nem, persze ha csak lekérdezed az elsőt.
Szerintem itt felesleges ezzel foglalkozni, alapvetően a hívónak ismernie kell, hogy mit kap vissza, ez a hiba úgyis nagyon gyorsan kiderül a tesztelés során.
Akkor persze kéne esetszétválasztás, ha többféle objektumot kaphatunk vissza, de az pedig szerintem kerülendő... -
#6614
floatr
veterán
Aethelstone
#6613
floatr
veterán
válasz
Aethelstone
#6613
üzenetére
De egész jól. Kéne még pár komment a témában
Mindenesetre nekem ez a fajta féltípusosság kicsit olyan nesze semmi fogd meg jól. A parametrizált osztályok és metódusok még az öröklődési szabályokat is átírják, ami azért gáz egy ennyire deklaráltan OOP nyelv esetében.
-
#6601
beleszólok
senior tag
Aethelstone
#6574
beleszólok
senior tag
válasz
Aethelstone
#6574
üzenetére
OK. Ha java-t akarok, mit javasolsz RTFM címszó alatt? (online, ingyenesen elérhető - nekem ez már rég csak hobbi, anyagi keret már nem nagyon van rá)
És design pattern témában?
Ebből találkoztam olyanokkal, mint Factory, Singleton(sokak szerint ez felejtős), Dependency Injection, Decorator - ezen volt pár apróbb vitám, mert valahol azt olvastam, hogy a pythonbeli decorator ennek a megvalósítása, mások szerint viszont semmi köze hozzá).
MVC nem tudom, mennyire sorolható ide... -
#6594
floatr
veterán
Aethelstone
#6592
floatr
veterán
válasz
Aethelstone
#6592
üzenetére
Mondjuk engem azért végtelenül bosszant az, ahogy mostanában alakulnak a dolgok a való életbeli projekteken: a legdurvább bleeding edge technológia Liferay alatt struts. Kicsit tényleg olyan fortran 77-es feelingje van az egésznek
-
#6593
floatr
veterán
Aethelstone
#6592
floatr
veterán
válasz
Aethelstone
#6592
üzenetére
És ez saccra a lambdával is így lesz. Ettől függetlenül gagyi...
-
#6587
emvy
félisten
Aethelstone
#6586
válasz
Aethelstone
#6586
üzenetére
Mint a ... ? A C++-al nem erdemes hasonlitani, mert ott nincsenek generikusok, csak templatek, az meg tok mas, a <> jelolesen kivul sok kozuk nincs egymashoz. A .Net-hez kepest miert kenyelmesebb a Java generikus-megvalositas?
-
#6585
emvy
félisten
Aethelstone
#6584
válasz
Aethelstone
#6584
üzenetére
Azert az, hogy runtime nem elerheto a tipusinformacio, nem annyira kenyelmes... meg ugye a boxing...
-
#6576
WonderCSabo
félisten
Aethelstone
#6573
WonderCSabo
félisten
válasz
Aethelstone
#6573
üzenetére
Én csak azt akartam mondani, hogy a párhuzam korrekt volt...
-
#6575
beleszólok
senior tag
Aethelstone
#6574
beleszólok
senior tag
válasz
Aethelstone
#6574
üzenetére
Lásd lambda hiánya, mint egyetlen példa...
Hány éven át sírt miatta a sok tudatlan?
(ha jól rémlik, a 7-es vagy 8-as talán már tud ilyet is) -
#6574
Aethelstone
addikt
Aethelstone
#6573
Aethelstone
addikt
válasz
Aethelstone
#6573
üzenetére
Plusz az a tapasztalatom, hogy a Java(egyéb nyelvek) fejlesztői nagyon sok esetben nincsenek teljesen tisztában a nyelv adta lehetőségekkel, hanem ahelyett, hogy ezen hiányosságaikat pótolnák, nyavalyognak, hogy miért nincs ez meg az a nyelvben, jóllehet ha nem is pontosan úgy, ahogy elképzelik, benne van, max. használni kellene pár design patternt, meg fantázia meg RTFM!
-
#6572
WonderCSabo
félisten
Aethelstone
#6571
WonderCSabo
félisten
válasz
Aethelstone
#6571
üzenetére
De, jogos az összehasonlítás, mert azokban a nyelvekben, ahol van operátortúlterhelés (pl. python, C++), ott a collection osztályoknál és indexelő operátort használnak. Ezt hiányolja beleszólok.
-
#6547
axioma
veterán
Aethelstone
#6535
axioma
veterán
válasz
Aethelstone
#6535
üzenetére
OK, amennyiben exception-nel kiegeszited a null helyet, akkor igaz. Mas kerdes, hogy egy egysoros try-catch csak az IllegalArgumentException elkapasara (mondjuk) mennyire felelsleges bonyolitasa (=rosszabb olvashatosaga) a kodnak. Ha visszaterunk az adatsor kiertekelesre, ahol jonnek az ertelmes adatok 1..99, a hiba meg a -1, es az osszes feladat mindossze az atlagolas, akkor inkabb irnek egy if-et (persze nem a -1-re hanem megfelelo beszedes konstansra), hiszen a cel nem az hogy lealljunk es tovabb ne is csinaljuk a lekerdezest, hanem a jelolt adatot ne vegyuk figyelembe, kezeljuk mashogy (akar az meg egy statisztikai szamlalot novel). Ezt hiaba lehet leirni exception-nel is, en erosen agyuval verebre esetnek ereznem.
Sot, az exception eroltetese a hibajelzo visszateresi ertekkel szemben szerintem csokkenti a kod fuggvenyekre bontasi hajlandosagat. Azt elismerem, hogy igy meg a kepernyore is kikerulo nullpointerexc.-k jellemzoek tulsagosan... az arany kozeputat kene megcelozni. -
#6546
floatr
veterán
Aethelstone
#6543
floatr
veterán
válasz
Aethelstone
#6543
üzenetére
Attól függ. Ha private adattagokkal smúzolsz, akkor kell egy kis dinamikus proxy (cglib, asm), és már megint lelépi a kiccsákókat.
-
#6544
floatr
veterán
Aethelstone
#6543
floatr
veterán
válasz
Aethelstone
#6543
üzenetére
Hú megint hitvita...
-
#6542
floatr
veterán
Aethelstone
#6541
floatr
veterán
válasz
Aethelstone
#6541
üzenetére
Hogy egy ismerősömet idézzem az ilyen kiindulási alapoknál: "ebből még bármi lehet"
De ahogy érzedAzért ez a "heavyweight" kissé molesztáló a springre nézve
ahhoz képest h a j2ee-nek annó ez volt a light alternatívája -
#6537
Cathfaern
nagyúr
Aethelstone
#6535
Cathfaern
nagyúr
válasz
Aethelstone
#6535
üzenetére
"Üzleti logika szempontjából az üres lista pont annyit ér, mint a null referenciával rendelkező."
Nem igazán. Üzleti logika szempontjából az üres lista azt jelenti, hogy pl. egy lekérdezésnek nincs találata, a null referencia pedig azt, hogy valami programhiba történt. Előbbi esetben elég megjeleníteni az üres listát, utóbbi esetben viszont figyelmeztetni kell a usert, hogy nem az történt, mint amit szeretett volna. -
#6536
floatr
veterán
Aethelstone
#6532
floatr
veterán
válasz
Aethelstone
#6532
üzenetére
Én ezt springgel oldanám meg egy felhasználási területtől függő scope-ban élő beannel
(#6531) beleszólok globális változó mint olyan nem is szabad h legyen, mert nem menne át a kód review-n
A VM egyébként is moduláris a classloader tekintetében; szóval relatív a globális. Egy kontextusban lehet alkalmazásra nézve globális valami, de nem szabad elfelejteni, hogy több kontextus is szaladgálhat egy VM alatt. Workaroundként a public static változókat szokták néha használni, de nem bátorítanálak erre. -
#6534
axioma
veterán
Aethelstone
#6525
axioma
veterán
válasz
Aethelstone
#6525
üzenetére
A listas peldaddal nem ertek egyet. Mert lehet, hogy ervenytelen, lehet hogy ervenyesen ures, es lehet hoyg nem ures. Ha az ervenytelent az uressel jelzed, akkor nem tudod megkulonboztetni a vegen, hogy ez most egy hasznalhato adatsor vagy sem... (mint amikor rarakjak egy meresi adatsorra a -1 -et ervenytelennek, de amikor az utolso 100 adatbol statisztikat kell csinalni, bamban azt is beleatlagoljak... lattunk ilyet kiszallitott kodban, nem java volt, de nem kis rendszer resze). Termeszetesen a listat is tovabb lehet fejleszteni, hogy tudja magarol hogy ervenyes-e, de azzal csak technikailag szuntetted meg a null-t, az ertekadas le fog futni ervenytelen ertekre is - ott is ahol nem figyelsz ra, mert nem lathatoan jon vele az info, hogy itt me'g hiba is lehet, vagy ez mar lecsupaszitott tuti ertek. Az meg nyilvan abnormalis, hogy minden egyes hasznalat elott megprobalod kicsomagolni.
Jelzem hogy en nem akarom a null-t szamuzni mindenaron, csak megertem azt a fajta logikat is, es nem tartanam problemanak atterni ra, kicsit jobban absztraktalva lenne mar a fuggveny megirasakor, hogy van-e hibaag. Vagyis belatom, hogy meg lehetne azt nagyon jol es megszokas utan kenyelmesebb programozast biztositoan csinalni. (Nagyon absztraktul nezve ez kivalthatja az exception dobasi rendszert is, a visszateresi ertekbe is becsomagolhato, mondhatnank csak az exception vagy a valos ertek lehet benne, a try-catch meg oly mindegy hogy honnan kihamozott adat alapjan mukodik.) -
#6531
beleszólok
senior tag
Aethelstone
#6530
beleszólok
senior tag
válasz
Aethelstone
#6530
üzenetére
No igen, ez megint vallási téma?
Egyik oldal: getter/setter, másik oldal: inkább publikus, de legalább protected.
(bár ez lehet, hogy python specifikus volt, amiben nincs igazán protected... kicsit bizonytalan vagyok) -
#6513
axioma
veterán
Aethelstone
#6512
axioma
veterán
válasz
Aethelstone
#6512
üzenetére
Szerintem itt elvi uton van elteres; a lenyeg nem a case-en van, hanem hogy case nelkul nem tudsz erteket adni a celvaltozonak kozvetlen -- azaz hogy tevedesbol se tudod leirni, hgoy enOsztalyom=enFuggvenyem() es utana rad van bizva, hogy case-elsz vagy sem null miatt, hanem a visszateresi erteked muszaj vizsgalnod, azzal tudod kiszedni a valodi erteket belole.
-
#6511
emvy
félisten
Aethelstone
#6510
válasz
Aethelstone
#6510
üzenetére
Itt szepen es erthetoen leirjak (az elso valaszban).
De akkor roviden en is leirom -- egy klasszikus pelda a megoldasra: Option tipus.
Ha van pl. egy fuggvenyed, ami Integer ertekkel ter vissza, akkor a fordito garantalja, hogy az Integer lesz, es nem null. Ha egy masik, alapvetoen Integert visszaado fuggvenyed nem mindig tud visszaterni Integerrel, mert pl. kivetelt dobhat, vagy ilyesmi, es nincs mit visszaadni, akkor a fuggvenyed visszateresi erteke legyen egy Option ertek, amit viszont nem tudsz Integerkent hasznalni, csak ugy, ha mindenkepp ellenorzod, hogy van-e erteke vagy sem.
Option ret = enFuggvenyem();
switch ret {
case None: print "Nincs visszateresi ertek"
case Integer(i): print "Az Integer ertek: " + i.toString()
}Sokfele megoldas van, a lenyege az, hogy nem kerulhetsz olyan szituacioba, ahol elfelejted ellenorizni, hogy valami null-e vagy sem, mert a compiler garantalja, hogy vagy tuti van ervenyes ertek, vagy leellenorizted.
Ahogy Hoare is mondja (akit gondolom nem kell bemutatni):
I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement.A lenyeg, hogy a nullreferencia nem egy szukseges rossz, hanem igazabol tok felesleges, amit a korai nyelvekbe raktak bele, hogy kicsit egyszerubb legyen megirni a compilert, es itt ragadt velunk. Csomo nyelvben (akar JVM alapu nyelvekben is) megoldottak, hogy ne legyen.
-
#6509
emvy
félisten
Aethelstone
#6508
válasz
Aethelstone
#6508
üzenetére
Mindenkinek az a normalis, amit megszokott. Gondolom a topicban senki nem haborodik fel azon, hogy a Java-ban van null erteku referencia, pedig talan a legrosszabb design hiba az egesz C/Java/C#/etc. nyelvi hagyomanyban, minden nap milliok futnak bele, pedig tipusos nyelvben siman el lehetett volna kerulni a letezeset (es akkor egyszeruen nem lenne NullReferenceException...).
-
#6502
beleszólok
senior tag
Aethelstone
#6499
beleszólok
senior tag
válasz
Aethelstone
#6499
üzenetére
Na ja... anno még tanultuk a goto használatát. (COBOL, PL/I, BASIC)
Később azt mondták rá, hogy az ördögtől való. Minap olvastam valahol egy kis írást, amiben azt fejtegették, hogy mégsem, sőt...
-
#6500
floatr
veterán
Aethelstone
#6499
floatr
veterán
válasz
Aethelstone
#6499
üzenetére
A Thread semmiképpen nem lehet jó mint leszármaztatási alap, trust me
Amikor egy osztály olyanokkal van tele, hogy "native", és le akarod származtatni, akkor villog a felkiáltójel.Bár ettől függetlenül nem értem a kötekedését, teljesen értelmetlen.
-
#6498
beleszólok
senior tag
Aethelstone
#6497
beleszólok
senior tag
válasz
Aethelstone
#6497
üzenetére
Akkor most olvasd el még1x - a végére szerkesztettem a magyarázatomat
De hogy még érthetőbb legyen: épp a fentiek miatt itt nem nagyon lehet szó hitvitáról, de ugye egy ilyen állítást illik megindokolni. -
#6496
beleszólok
senior tag
Aethelstone
#6495
beleszólok
senior tag
válasz
Aethelstone
#6495
üzenetére
"szerintem nem ilyen".
De, ilyen. Ha szigorúan vesszük az elveket. (és én hajlamos vagyok rá, hogy így tegyek)
Egyébként komolyan ajánlom, hogy olvasd el azt a stackoverflow-s beszélgetést (azt meg még inkább, hogy még a legkevésbé fontos dolgoknál se kezeld ilyen nagyvonalúan ezeket, mert a végén úgy jársz, mint én- bocs, azt hittem, a kérdező reagált)---
Amit linkeltél, azt elolvastam. A fentieket arra írtam, hogy hitvitát emlegettél korábban és szerintem aki ebből a Thread kiterjesztése mellett voksol (magyarán nem te), az felrúg bizonyos elveket, amiket nem kellene. -
#6494
beleszólok
senior tag
Aethelstone
#6486
beleszólok
senior tag
válasz
Aethelstone
#6486
üzenetére
No, végre billentyűzet előtt (gyűlölöm az android virtuális billentyűit
)
Szóval... Te itt hitvitáról beszéltél korábban.
Én olvastam olyan dolgokról, mint S.O.L.I.D. elvek, olvastam Uncle Bob Tiszta kód c. könyvét stb.
Most, hogy kicsit részleteztétek, miről van szó, szerintem a te verziód "a" megoldás, a másik felrúgja az OOP alapokat is, tehát szó sincs hitvitáról.
Ami picit megkavart, hogy pythonnal foglalkozom valamennyire és ott a szálak létrehozására olyan példákat találtam anno, hogy a multithreading.Thread osztályból célszerű származtatni.
Jelen esetben én úgy éreztem, az "extends Thread" felrúgja a SOLID elvek közül azt, amelyik szerint a leszármazottat a szülő helyére téve pontosan ugyanúgy kell viselkednie, mint a szülőnek.
Na most, ha "extends Thread" és felülírod benne a run metódust, akkor máris felrúgtad a fenti elvet, mivel a run() a szülőben nem csinál semmit, a leszármazottban viszont...
Persze az sem kizárt, hogy én értelmezem félre ezeket az elveket. Amikor suliban tanultam, még nem nagyon volt szó OOP-ról, nemhogy ezekről az alapelvekről és elég rég elhagytam a pályát.Egy kis olvasnivaló e témában (erősen ajánlott azoknak, akik hitvitát csinálnának belőle
) : http://stackoverflow.com/questions/541487/implements-runnable-vs-extends-thread -
#6485
beleszólok
senior tag
Aethelstone
#6483
beleszólok
senior tag
válasz
Aethelstone
#6483
üzenetére
Indok? (Nem kötekszem, tényleg érdekel - elő akarom szedni újra a javat, minden ilyen infó érdekes)
-
#6484
Oppenheimer
nagyúr
Aethelstone
#6483
Oppenheimer
nagyúr
válasz
Aethelstone
#6483
üzenetére
Másból nem kellett leszármaznia, csak egy interfacet valósít meg, így kézenfekvõnek tūnt, hogy Threadbôl származzon.
-
#6470
emvy
félisten
Aethelstone
#6469
válasz
Aethelstone
#6469
üzenetére
Persze, hasznaltam eleget, remes.
-
#6467
emvy
félisten
Aethelstone
#6466
válasz
Aethelstone
#6466
üzenetére
Tudom, hogy viccelsz
, de valojaban pont errol van szo. -
#6465
fordfairlane
veterán
Aethelstone
#6456
fordfairlane
veterán
válasz
Aethelstone
#6456
üzenetére
Miért, thread-kezelést építeni egy app-level nyelvbe nem hülyeség?
-
#6460
Karma
félisten
Aethelstone
#6459
Karma
félisten
válasz
Aethelstone
#6459
üzenetére
Szerintem ugyanaz a stílusú kód, azaz egy anonim objektum létrehozása egy metódus implementálásáért, nem lesz kevésbé olvasható a lambdától. Sőt, akkor már a tömörebb jobb, mert például a Java stílusú "new Runnable() { void run() { ... } }" alapjáraton is nagyon belterjes.
Hogy az anonim subclassok mennyivel jobbak/rosszabbak egy nevesítettől, na az már más kérdés.
-
#6458
SirRasor
addikt
Aethelstone
#6452
SirRasor
addikt
válasz
Aethelstone
#6452
üzenetére
Köszönöm mindenkinek a válaszokat; közben feltettem az Eclipse-t és elsőre tetszik
-
#6445
Oppenheimer
nagyúr
Aethelstone
#6441
Oppenheimer
nagyúr
válasz
Aethelstone
#6441
üzenetére
Én azért féltem a javat. Még mindig keresem a helyem a világban, lassan ki kéne találnom mi érdekel igazán. Eddig java, dotnet, cpp volt a sorrend, de állandóan változott. Most mégképlékenyebb lett.
-
#6423
Pimpő
tag
Aethelstone
#6421
Pimpő
tag
válasz
Aethelstone
#6421
üzenetére
Túllihegitek.
Highly advanced single user remote repository with local accelerator cache. Oszt pazony
-
#6414
WonderCSabo
félisten
Aethelstone
#6411
WonderCSabo
félisten
válasz
Aethelstone
#6411
üzenetére
Valahogy azt sejtem, hogy ez nem céges projekt, de igazad van.
Pimpő: Szóval igazából csak Te használtad a repot? És a dropbox syncelte, és nem is a hg push?
-
#6396
jetarko
csendes tag
Aethelstone
#6395
jetarko
csendes tag
válasz
Aethelstone
#6395
üzenetére
A minden oldal alatt azt értettem, hogy minden függvény ahol meghívom az adatbázis-t, de értem a lényegét, ami logikus is, hogy mindenhol try-ba kell raknom.
-
#6394
jetarko
csendes tag
Aethelstone
#6393
jetarko
csendes tag
válasz
Aethelstone
#6393
üzenetére
Hm, lehet benne valami, lehet átírom az egészet ilyenre vagy a következőt így kezdem.
Jelenleg elég sok oldalon van adatbázis kezelésem. Amikor elkezdtem csinálni,akkor eszembe se jutott, hogy lehet, hogy az adatbázis nem érhető el, ezért nem kezeltem sehol, hogy tényleg elérhető vagy nem. Most az egyik oldalon beraktam try-ba a lekérdezést, ezért ott letudom kezelni, de a többi oldalon jön a hiba, ha az adatbázis kapcsolat nincs.
Minden egyes helyen try-ba kéne raknom vagy van erre valami szebb megoldás? Hibernate-t használok, ha ez számít. -
#6390
jetarko
csendes tag
Aethelstone
#6387
jetarko
csendes tag
válasz
Aethelstone
#6387
ü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.
@Override az miért van a @RequestMapping-nál? -
#6385
jetarko
csendes tag
Aethelstone
#6384
jetarko
csendes tag
válasz
Aethelstone
#6384
üzenetére
Ezt nem egészen értem, tudnál írni egy példát? Meg ez arra jó, hogy ha tudsz egy url-t, akkor azonnal odatudsz ugrani a fv-hez? A saját alkalmazásomba már van 50-60 url 7-8controllerbe és nem rögtön tudom mi hol van, néha szívok is ezzel 1-2percig
-
#6383
floatr
veterán
Aethelstone
#6382
floatr
veterán
válasz
Aethelstone
#6382
üzenetére
MVC esetében kifejezetten problémás, hogy az útvonalak az osztályokban szétszórva vannak deklarálva. Ez baromira megnehezíti akkor a supportot, amikor egy útvonalat adnak a hibajegyben - mert mást nemigen tudnának. Lehetnek ütközések a projektben, két projekt komponenseiben, összeolvasztáskor; ezt egy külső konfig meg tudhatná oldani.
Az adatbázis kókányolás meg tűzoltás volt, nem tervezési hiba. Tervezni sok mindent lehet, de nem mindent. Ezért mondom, hogy nagy öngól az annotáció - konstans páros hosszú távon. Persze lehet nem egyetérteni, de eddig ezt tapasztaltam.
-
#6381
floatr
veterán
Aethelstone
#6380
floatr
veterán
válasz
Aethelstone
#6380
üzenetére
Transactional és függőség esetében is volt már, hogy konfiguráción kellett változtatni az éles környezetben - szerencsére XML-ben. De itt konkrétan az MVC-t említettem, ahol pl. konstansok az útvonalak. És bármennyire is nehéz elképzelni, volt olyan helyzet, hogy egy milliós méretű tábla esetében oszlopot kellett cserélni átmenetileg.
A kérdés csupán annyi, hogy kell-e ehhez a fejlesztő és egy fejlesztői környezet, egy teljes telepítés vagy a patchelés kockázata, ha este tízkor jön az email.
Szerk.: de nagyon elkanyarodtunk a témától. Nem vitatom, hogy kényelmesebb fejlesztéskor, de ugyanennyire szívás a későbbiekben.
-
#6379
floatr
veterán
Aethelstone
#6378
floatr
veterán
válasz
Aethelstone
#6378
üzenetére
Nomost itt kanyarodunk akkor vissza az hibernate marhaságaihoz, az annotált osztályokhoz. Ugyanezért nem csípem a Spring MVC annotációkat, meg a többit, mert mindent beéget a kódba, és a fenti példával élve esély sincsen rá, hogy ez bármennyire is kiszervezhető lenne anélkül, hogy eldobnád az annotációkat totálisan, miközben a szintaktika gyakorlatilag átver.
-
#6377
floatr
veterán
Aethelstone
#6367
floatr
veterán
válasz
Aethelstone
#6367
üzenetére
Az első felvetésben egyetértünk h kinek mi fekszik.
A második témában viszont úgy tűnik h elbeszélünk egymás mellett. Arra gondoltam első sorban, hogy az önmagában egy bődületes hiba, hogy egy kód fixen beégetett konfigurációt tartalmaz fordítás-idejű (de idétlen szó ez) konstansokat használó annotáció formájában.
Azt viszont nem tudnám megmondani, hogy hányszor fordult elő az, amikor a supporttal kellett vérre menően csatázni, és telepített alkalmazások alatt a konfigot és/vagy a DB-t változtatni. Véleményem szerint nem valóban enterprise-ready egy ilyen annotált kód. (függetlenül attól, hogy néha ráviszi a szükség az embert). Azon meg végképp nem segít semmi elmélet, hogy a nyelv szintaktikája és a fordító trükkjei nem kompatibilisek.
-
#6375
Sokimm
senior tag
Aethelstone
#6374
Sokimm
senior tag
válasz
Aethelstone
#6374
üzenetére
Most már jó...
Elnézést a buta kérdésem miatt, amire megtaláltam a választ. Ez az internetes lexikonok "TÉMA OFF" címszavára a tökéletes példa. A "semmi értelme az írásomnak" című fejezetet olvastátok. 
-
#6371
WonderCSabo
félisten
Aethelstone
#6369
WonderCSabo
félisten
válasz
Aethelstone
#6369
üzenetére
Értem, nyugi, csak pongyola volt a megfogalmazás.
-
#6368
WonderCSabo
félisten
Aethelstone
#6367
WonderCSabo
félisten
válasz
Aethelstone
#6367
üzenetére
Nyilván mindenkinek más a szokása, de static final változónak én ott adok értéket, ahol a deklaráció van.
Máshol nem is lehet.
-
#6358
floatr
veterán
Aethelstone
#6357
floatr
veterán
válasz
Aethelstone
#6357
üzenetére
Elcseszett dolgokat műveltek az 1.5-től kezdődően a java-val, függetlenül attól, hogy mit tervez az ember.
A múltkor egy olyan bakiba futottam bele, ami miatt a generic-es metódusok öröklése akadt össze, pedig a nyelv szabályai szerint működnie kellett volna, de megint csak a hakkolt fordítási procedúra összegányolt mindent. Szvsz ki kellett volna dobni a régi leírókat, és hagyni a kompatibilitást a vérbe, mert most tele van tervezési hibával az egész.
-
#6356
floatr
veterán
Aethelstone
#6355
floatr
veterán
válasz
Aethelstone
#6355
üzenetére
Ott a problémám ezzel, hogy így a konstans field a nyelv szerint ugyanaz, miközben kétféleképpen kezeli a fordító.
De FYI egy régebbi lib elrontott tervezési mintáját próbáltam átvágni -- mint kiderült -- sikertelenül
-
#6354
floatr
veterán
Aethelstone
#6353
floatr
veterán
válasz
Aethelstone
#6353
üzenetére
Most egyelőre vonatkoztassunk el az értelmétől
A nyelv elvileg megengedi, de a fordító hakkolás nem.
Amúgy szenvedtem valamivel, és ebbe futottam bele. De ha egy bárakármilyen statikus metódussal adsz neki értéket, akkor ugyanide lyukadsz ki.
private static final String BAR = FooUtil.getBarNameFromResource();
-
#6268
emvy
félisten
Aethelstone
#6260
válasz
Aethelstone
#6260
üzenetére
> "szakma krémje"
Azt irtam, hogy a szakma kremje dolgozik ezeken a problemakon, ezert valoszinuleg a problemak valosak.
-
#6262
boost
veterán
Aethelstone
#6261
boost
veterán
válasz
Aethelstone
#6261
üzenetére
De miért ++i? Kapásból ki is hagyná az első elemet, ha pl egy listán, tömbön fut végig
-
#6254
emvy
félisten
Aethelstone
#6253
válasz
Aethelstone
#6253
üzenetére
Nem hinnem
-- eleg intenziven foglalkozik ezekkel a szakma kremje az utobbi evtizedben, par apro dolog meg a Java-ba is beszivarog (lasd Java 8). Persze ugy nehez megitelni a dolog problematikussagat, ha mondjuk a Java-n kivul nem programoztal egyeb kornyezetekben. Ez az egyik oka, hogy erdemes kb. evente megtanulni legalabb alapfokon (egy kisebb projekt erejeig) egy uj nyelvet, szelesiti a latokort -- ha mondjuk senior fejleszto korodra mar irtal hasznalhato dolgokat legalabb 5-8 nyelvben, az mindenkepp hasznos. Csomo minden van, ami nem hianyzik addig, amig egyszer nem lattad -- pl. csomo Java-fejlesztot nem idegesit az, ahogy a generikusokat implementaltak a Java 5-ben, pedig egeszen elkepesztoen fajdalmas kb. minden mas implementaciohoz kepest. Ha viszont mittudomen, volt mar elotte C++ vagy C# tapasztalat, akkor legalabb tudod, hogy hogy kene mukodnie, ha rendesen meg van csinalva (es forditva is igaz, amig az ember pl. csak .Netet latott, addig nem ertekeli, hogy pl. a build rendszerek mennyivel jobbak JVM platformon; vagy a temahoz kapcsolodva: a mai napig ledobbenek, hogy 1000-1500 sornyi Java kod funkcionalitasa Scala-ban vagy Clojure-ben 50 sor, es vilagos, mint a nap).Tenyleg erdemes a lenti rovid eloadast (is) megnezni, meg esetleg megcsinalni az Odersky-fele (SZUPER) Scala-kurzust:
https://www.coursera.org/course/progfunSzerk.: egyeb pelda: ha valaki meg nem futott bele abba, hogy mekkora fajdalom a single dispatch, az hazudik
-
#6245
jetarko
csendes tag
Aethelstone
#6238
jetarko
csendes tag
válasz
Aethelstone
#6238
üzenetére
Valahol el kell kezdeni és mivel suliba ilyet nem tanítanak, ezért első körbe az ilyen netes tutorialokat nézegettem, de azt én is leszűrtem, hogy nem az igaziak, már ha egyáltalán működnek.
Suliba belenéztünk kicsit JPA-ba, de amúgy csak SE volt.
Majd most utána akarok nézni a memory profiling-nak meg az alkalmazás szerverek konfigurálásának, mert az, hogy én localhost-ba elszórakozok egy projectel az oké, de ha ez éles project lenne, akkor gondolom számítana memória használat, skálázhatóság és még nem tudom mik.
Még fél évig suli mellett nem tudok menni melózni, ezért addig marad az itthoni tanulgatás, mert érdekel a java ee világa.És miből lenne érdemes tanulni a netes tutorialok helyett? Álljak neki olvasni az igencsak hosszú hibernate és spring doksit?
Ha már szóba jöttek a design pattern-ek párat mondanátok, amiket érdemes lenne tanulgatni, használni ebben a témában?
-
#6241
floatr
veterán
Aethelstone
#6240
floatr
veterán
válasz
Aethelstone
#6240
üzenetére
Régebben én is szkeptikus voltam, de ahogy látom ahogy hígul a szakma, és kik mondják magukat java fejlesztőnek, neadjaég senior-nak, azóta úgy érzem, hogy az egyik legjobb ötlet volt a minták nyomatása.
-
#6239
floatr
veterán
Aethelstone
#6238
floatr
veterán
válasz
Aethelstone
#6238
üzenetére
És egy C/C++ fejlesztő ismerős kérdezte, hogy mi a fenéért nyomják ezeket a tervezési mintákat... hát ezért.
-
#6237
floatr
veterán
Aethelstone
#6236
floatr
veterán
válasz
Aethelstone
#6236
üzenetére
Ja, hát ez a kézimunka elég nagy marhaság a példákban, pláne hogy mindenki ebből tanulna a zinternetrül. Épp most tépem a hajam, hogy egy olyan projektbe ugrottunk be, amit olyan "szakik" készítettek elő, akik netes példákból ollózták össze a tudásukat.
-
#6235
floatr
veterán
Aethelstone
#6233
floatr
veterán
válasz
Aethelstone
#6233
üzenetére
JTA vagy sem, ha már Spring-et használ, akkor ott van a @Transactional(propagation=Propagation.SUPPORTS) vagy REQUIRED
-
sunnysys
tag
válasz
Aethelstone
#6181
üzenetére
Köszönöm!
Akkor keresek ilyen irodalmat, mert enélkül csak a saját logikámra támaszkodhatok, ami valószínűleg egy idő után már korlátoltan lesz csak elég.
"Gyorsan haladni? Alapvető szabály, hogy akkor lehet igazán hatékonyan megtanulni programozni, ha van értelmes feladat. Nem telefonregiszter és nem DVD kölcsönző nyilvántartás. Viszont komolyabb, életszagú, szopós feladatok csak éles munkahelyi környezetben szoktak adódni
"Na, de honnan tudhatom, hogy mi az értelmes feladat? Teljesen kezdő vagyok, amíg tanárt nem találok, csak netről, könyvekből tájékozódhatok. Munkahelyi környezet pedig egy jó ideig nem áll majd rendelkezésre, gondolom.
-
#6222
jetarko
csendes tag
Aethelstone
#6190
jetarko
csendes tag
válasz
Aethelstone
#6190
üzenetére
Köszi a választ, örülök, hogy nem én vagyok ilyen béna, de a google skillemen van mit javítani mert hasonló dolgokat írtam be, de még se találtam stackoverflow-os kérdést erre.
Most magamnak írogatok csak programokat ezért az adatbázis mérete nyilván kicsi, de ha van 1millio rekord akkor az adatok lekérése Set-tel sokkal lassabb mint bármelyik List a beszúrási idő miatt. Vagy az elején teljesen felesleges hatékonysági problémákon gondolkodnom?
Amúgy netes tutorial alapján csináltam dao és service-ket és ahol konkrétan lekérem az így néz ki:
public Team getTeamById(int id) {
Session session = this.sessionFactory.getCurrentSession();
Team t = (Team) session.get(Team.class, new Integer(id));
return t;
}A team entitásban meg ugye csak simán van egy Set<Driver> és aztmondom, hogy getTeamById(1).getDrivers() szóval nem látom hova rakhatnám a distinct-et ezért marad Set.
Vagy dobjam a dao és service osztályt és ilyen namedQuery-ket írjak? -
#6221
floatr
veterán
Aethelstone
#6194
floatr
veterán
válasz
Aethelstone
#6194
üzenetére
Mondjuk sok támpontom nem volt, csak a kolléga kódja, ő meg égert használt annotációban
-
#6220
WonderCSabo
félisten
Aethelstone
#6219
WonderCSabo
félisten
válasz
Aethelstone
#6219
üzenetére
OK, valóban kezdünk eltérni a témától, sorry.
-
#6218
WonderCSabo
félisten
Aethelstone
#6217
WonderCSabo
félisten
válasz
Aethelstone
#6217
üzenetére
OK, azért szerintem jogos a duplikált sor lehetősége, különben a DISTINCT operátor értelmét vesztené, csak ezt akartam mondani.
Az viszont lehet, hogy így objektum-relációs leképezésen nem nagyon lehet használni, ebben valszeg igazad van, elnézést. -
#6216
WonderCSabo
félisten
Aethelstone
#6214
WonderCSabo
félisten
válasz
Aethelstone
#6214
üzenetére
Nyilván az ID-k eltérhetnek, de azt a java kódban az equals metódus-nak nem kell feltétlenül figyelembe vennie, és akkor máris egyenlő két egyed.
Persze az ilyen dolog is még ki fog bukni normalizáláskor, de egyrészt nem kell minden adatbázisnak x. normálformában lennie, másrészt ez az egyszerű példa is mutatja, hogy nagyon sántít ez a dolog.Én OrmLite-ot használok ORM-ként Android-on, az sosem csinált ilyet. Most rákerestem erre a Hibernate OneToMany duplicates problémára, és mindenhol azt olvastam, hogy rosszul volt használva a cucc.
Én elhiszem hogy ez így működik, mivel nem használtam még Hibernate-et (se semmilyen JPA implementációt), de akkor is nagyon furcsának tartom ezt. Ha esetleg erre van doksitok, ami leírja hogy ez az elvárt működés, az hasznos lenne.
-
#6215
Szmeby
tag
Aethelstone
#6213
Szmeby
tag
válasz
Aethelstone
#6213
üzenetére
És ezen álláspontjukat nagyon arrogánsan képesek védeni is. Borzasztó lekezelően viselkednek a segítséget kérőkkel, cserébe viszont semmi konstruktívval nem tudnak szolgálni. Persze én vagyok a hülye, hogy a Hibernate fórumon kérek segítséget a Hibernate-tel kapcsolatban.
-
#6214
Aethelstone
addikt
Aethelstone
#6213
Aethelstone
addikt
válasz
Aethelstone
#6213
üzenetére
Lejárt a módosítás. Ha nem unique sorok vannak, akkor ott a normalizálás sérül....azt meg a kukába kell vetni ilyenkor.
-
#6209
Mukorka
addikt
Aethelstone
#6208
Mukorka
addikt
válasz
Aethelstone
#6208
üzenetére
Akarom mondani singleton
-
#6207
Mukorka
addikt
Aethelstone
#6206
Mukorka
addikt
válasz
Aethelstone
#6206
üzenetére
Ha már úgy is van egy külön nem lazy metódusod erre akkor az jelzi hogy néha előfordul hogy kell minden. Sztem belefér, jobb mint fölöslegesen felhozni minden adatot és aztán hagyni hogy a hibernate fölöslegesen dolgozzon rajta. Igen, ízlés dolga
Kell írni sebesség teszteket rá és el lehet pöcsölni még vele egy csomót
(#6208) Aethelstone: Nem tudom, ritka jól sikerült objektum vagyok =)
-
#6205
Mukorka
addikt
Aethelstone
#6204
Mukorka
addikt
válasz
Aethelstone
#6204
üzenetére
Átírtam a választ
-
#6202
Mukorka
addikt
Aethelstone
#6201
Mukorka
addikt
válasz
Aethelstone
#6201
üzenetére
Akkor inkább a distinct, a set nem szép.
Igazából itt az a baj hogy egyszerre kéred le egy selectben. Esetleg át lehet írni hogy egy másik select hozza le a kapcsolatokat vagy ahogy nálunk sokan tolják (nem is szép) meghívni a size()-t, amit persze ti kikapcsolattatok azzal az extra annotációval.
-
#6200
Mukorka
addikt
Aethelstone
#6199
Mukorka
addikt
válasz
Aethelstone
#6199
üzenetére
Szerk: Már értem, nem a joinolt lista duplikált hanem maga a végeredmény. Ez látszólag tök jogos, a linkeden le is írja a választ erre
-
#6195
Mukorka
addikt
Aethelstone
#6194
Mukorka
addikt
válasz
Aethelstone
#6194
üzenetére
Véletlenül a CorrelationRule id nem a CorrelationRuleSet táblában van?
Nekem gyanús hogy a distinct azért oldja meg mert így nem talál több ugyanolyan recordot amiről aztán a hib megállapítja hogy ugyanaz de a hozzá tartozó kapcsolatokat hozzáadogajta a meglévő listához.
(#6194) Aethelstone: Nem tudom milyen hibernate verziót használtok de mi százával használunk ilyen kapcsolatot és az tuti hogy ilyen hibával nem találkoztam még
-
#6193
floatr
veterán
Aethelstone
#6190
floatr
veterán
válasz
Aethelstone
#6190
üzenetére
Eager-hez minek fetch?
Egyébként erre gondoltam, igen
-
#6192
Aethelstone
addikt
Aethelstone
#6190
Aethelstone
addikt
válasz
Aethelstone
#6190
üzenetére
Nos, a Hibernate doksi szerint teljesen normális, hogy duplikátumok vannak. A Set használatát javasolják.
-
#6187
Phvhun
őstag
Aethelstone
#6186
Phvhun
őstag
válasz
Aethelstone
#6186
üzenetére
Köszi.
Ikon kép miatt kell.
Szerk: Nézem ezt az Angster féle könyvet, mennyire gáz hogy kb 11 éves már? Érdemes ebből elkezdenem tanulni a 0-ról? Delphi és php-ben van sok tapasztalatom, szoval csak javát kezdem 0-ról.
Köszi azért.
Elnézést a buta kérdésem miatt, amire megtaláltam a választ. Ez az internetes lexikonok "TÉMA OFF" címszavára a tökéletes példa. A "semmi értelme az írásomnak" című fejezetet olvastátok. 
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Samsung Galaxy A54 - türelemjáték
- Parfüm topik
- Kerékpárosok, bringások ide!
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Kávé kezdőknek - amatőr koffeinisták anonim klubja
- Formula-1
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- EAFC 25
- Honda topik
- További aktív témák...
- DELL G2724D / Samsung Odyssey G5 1440p 165hz árak leírásban.
- Asus RTX 4070 12GB DDR6X - DUAL-RTX4070-O12G-EVO-DLSS 3 Garancia
- Apple iPhone 14 128GB, Kártyafüggetlen, 1 Év Garanciával
- Apple iPhone 14 Pro Max 128GB, Kártyafüggetlen, 1 Év Garanciával
- Új Apple iPhone 16 Pro 128GB, Kártyafüggetlen, 3 Év Garanciával
- BESZÁMÍTÁS! Microsoft XBOX Series X 1TB SSD fekete játékkonzol extra kontrollerrel dokkolóval
- LG 25GR75FG - E-Sport Monitor - FHD 360Hz 1ms - NVIDIA Reflex + G-sync - AMD FreeSync - HDR 400
- Azonnali készpénzes nVidia RTX 2000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
- BESZÁMÍTÁS! AOC 24P1 24 FHD 60Hz 5ms monitor garanciával hibátlan működéssel
- Bomba ár! Dell Latitude E5570 Touch - i5-6300U I 8GB I 256SSD I 15,6" FHD I HDMI I CAM I W10 I Gari
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged