Hirdetés
- Luck Dragon: Asszociációs játék. :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: MárkaLánc
- sziku69: Szólánc.
- gban: Meghalt Chuck Norris
- balojazz: Szódakészítés üzembiztosan és olcsón! Figyelem, csak hardcore szódázóknak!
- Elektromos rásegítésű kerékpárok
- suste: Openwrt Barrier Breaker 14.07 saját verzió Tp-link routerekre
- talmida: Változások 2. rész
Új hozzászólás Aktív témák
-
Szmeby
tag
válasz
togvau
#11180
üzenetére
Én inkább a Hibernate-re gyanakszom (vagyis az általad választott aktuális JPA implementációra), ő rakja össze az sql-t. A spring csak egy plusz réteget húz köré. Ezért is gondoltam azt, hogy az egyik megoldás egyből a hibernate-et szólítja meg, míg a másik átfolyik még néhány springes optimalizáción. Habár a spring egyik és másik modulja is képes gyökeresen eltérő "optimalizációkat" végrehajtani ugyanabból a kiindulópontból.
Szerintem sem sikerültek a legjobbra a hibernate default működési módjai ilyen-olyan esetekben, de tudod, ez ízlés dolga. A kedvencem, hogy Set, List, Collection, stb típusok esetén ceteris paribus teljesen eltérő lekérdezéseket rak össze végül. Külön öröm volt ezt debugolni.

Más fejlesztő más problémával meg örül neki, hogy pont úgy működik az általa összerakott izé, ahogy azt elvárja. A show_sql-nek nincs oka, hogy hazudjon.Megtanultam már, hogy minden hibernate által összeállított query-t le kell ellenőrizni, mert orbitális hülyeségeket, optimalizálatlan megoldásokat tud összerakni a háttérben. Vagy csak nekem vannak furcsa igényeim, ki tudja.

Örülök, hogy a fetch megoldotta a problémát.
Optimalizálj és jó lesz. 
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest

Optimalizálj és jó lesz. 