Új hozzászólás Aktív témák

• #11191 mobal nagyúr togvau #11180

  Új Válasz 2020-06-30 17:52:00 #11191

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  mobal

  nagyúr

  válasz togvau #11180 üzenetére

  Ezt meg kéne tudni csinálni szerintem nativ query nélkül is. Régen csináltam hasonlót:

  Optional<Deck> findByIdAndGame_Id(int id, int gameId);

  A deck entity-nek pedig volt egy ilyen tulajdonsága:

  @OneToOne
@JoinTable(
name = "games_decks",
joinColumns = @JoinColumn(name = "deck_id"),
inverseJoinColumns = @JoinColumn(name = "game_id")
)
@JsonIgnore
private Game game;

• #11184 Szmeby tag togvau #11180

  Új Válasz 2020-06-28 12:00:04 #11184

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Szmeby

  tag

  válasz togvau #11180 üzenetére

  "pl van 2 entity, 1-1 kapcsolattal."

  Na várj csak! Ha 1-1 kapcsolat van köztük, akkor miért OneToMany annotációt használsz? Mi történne, ha OneToOne-ra módosítanád?

• #11182 Szmeby tag togvau #11180

  Új Válasz 2020-06-28 11:32:46 #11182

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

• #11181 togvau senior tag togvau #11180

  Új Válasz 2020-06-27 23:24:13 #11181

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  togvau

  senior tag

  válasz togvau #11180 üzenetére

  join fetch megoldotta a 2 querys dolgot... de ezt miért nem tudja magatól? Főleg a default gyári queryknél, mint a findbyid.

Új hozzászólás Aktív témák