problémy s OneToMany včetně klauzule o filtru v jarním JPA

• Význam select d from TKBData d JOIN d.columns c WHERE c.name = column1 je

  1. Najděte objekt TKBData tam, kde má přidružený column objekt, pro který name je column1
  2. Jakmile se rozhodne, která data TKBD mají alespoň jeden column objekt, pro který name je column1 , pak vrátí všechny související column objekty které v JPA nemáte pod kontrolou. (viz Moje odpověď na další otázku ). Alternativou je napsat nativní sql a vrátit vlastní neentitní objekty
  3. Například máte TKBDATA_1 s column1 a column2 přidružen, máte také TKBDATA_2 s column3 související.
  4. Když spustíte dotaz, bude ignorovat TKBDATA_2 a rozhodne se vrátit TKBDATA_1 protože má alespoň jeden column objekt s name =column2 . Ale potom nemáte kontrolu nad tím, který přidružený column objekty, které se mají vrátit pro TKBDATA_1 a JPA vrátí všechny přidružené objekty sloupců
  5. Pokud si nejste jisti důvodem, přečtěte si o relaci hibernace. Jak poskytuje jedinečnou prezentaci jakékoli související položky v paměti. Je to základ pro jeho dirty checking a repeatable read

• Aktualizujte svůj @OneToMany následovně

   @OneToMany(fetch = FetchType.EAGER, 
           cascade = CascadeType.ALL, orphanRemoval = true)
   @Builder.Default
   @JoinTable(name = "TKBDATA_TKBCOLUMN", 
           joinColumns = @JoinColumn(name = "TKBDATA_ID"), 
           inverseJoinColumns = @JoinColumn(name = "COLUMNS_ID"))
   private Set<TKBColumn> columns = Sets.newHashSet();

• Pokud jde o dotazovací jazyk JPA, rád bych v pojmech dotazování myslel na kolekci objektů v paměti.

• Pokuste se tedy nyní popsat význam následujících dvou dotazů z hlediska objektů.

   select d from TKBData d LEFT JOIN d.columns c WHERE c.name = :name

           vs

   select d from TKBData d JOIN d.columns c WHERE c.name = :name

• Nezapomeňte, že na rozdíl od SQL, kde zde vybíráte libovolné sloupce, jste řekli, že chcete vybrat objekty TKBData a omezit, které objekty TKBData se mají vrátit.

• Chcete-li tedy dosáhnout stejného výsledku jako u vašeho nativního SQL, použijte druhý dotaz JPA

Poznámka:

I když jste ve svém dotazu SQL použili levé spojení, je to ve skutečnosti dotaz vnitřního spojení SQL, protože jste také použili where stavu k nejsprávnějšímu stolu na tomto spojení.