Adnotacje a criteria query

Adnotacje a criteria query
M4
  • Rejestracja:ponad 4 lata
  • Ostatnio:dzień
  • Postów:50
0

Czy tworzac zapytanie na encji przy pomocy Criteria brane sa pod uwage adnotacje?

Pytam bo mam encje ktora ma referencje w jedna strone do innejj encj, oznaczona jest przy pomocy @ManyToOne z dymyslnym fetch na eager. Tworzac zapytanie przez criteria referencja jest odpytywana w osobnym selekcie zamiast z left join...

Przyklad docelowy:

Kopiuj
@Entity
@Table(name="user")
public class User {
...
//Odpytanie leci w osobnym selekcie //zamiast z left join
@ManyToOne
private Address address;
...
}
edytowany 4x, ostatnio: maniek41
Zobacz pozostałe 4 komentarze
Riddle
@maniek41: staraj się nie używać gołych @ManyToOne w poście, dlatego że na 4programmers.net jest to wspomnienie użytkownika (ping). Stosuj formatowanie kodu inline, np `@ManyToOne`.
M4
Nie kompiluje sie bo nie o to chodzilo. To jest tylko pikazanie o jakie polaczenie mi chodzilo, a kodu jievmoge wrzucic niestety
Riddle
@maniek41: to chociaż pisz bez błędów składniowych. Poza tym, jeśli masz z czymś problem, to zrób to samo u siebie w prywatnym projekcie, i ten kod już możesz wrzucić
M4
Ok, tylko ze tutaj nie ma co wrzucac bo glownie mi chodzi tylko o to czy adnotacje typu eager fetch sa uwgledniane automatycznie w criteria czy trzeba jednak jawnie wywolac fetch na criteria i tyle
Riddle
@maniek41: To zdecyduj się. Raz piszesz To jest tylko pikazanie o jakie polaczenie mi chodzilo, a kodu jievmoge wrzucic niestety, a potem że "kod i tak się nie różni". Wrzuć poprawny kod na podstawie którego formowicze Ci mogą pomóc - albo prawdziwy, albo swój prywatny który przepisałeś. Wrzucanie kodu z błędem składniowym nie jest dobrym zaczątkiem pomocy.
ZD
  • Rejestracja:około 3 lata
  • Ostatnio:ponad rok
  • Postów:2310
1

@maniek41:

na zdrowy rozsądek nie ma powodów, aby przez criteria było inaczej optymalizowane niż JPQL
A że nie wszystko tam zawsze jest tak optymalne, jak by się marzyło ...

maniek41 napisał(a):

//Odpytanie leci w osobnym selekcie //zamiast z left join

bez realnego kodu odpowiedź daremna


If you put a million monkeys at a million keyboards, one of them will eventually write a Java program - the rest of them will write Perl
edytowany 1x, ostatnio: ZrobieDobrze
M4
  • Rejestracja:ponad 4 lata
  • Ostatnio:dzień
  • Postów:50
0
ZrobieDobrze napisał(a):

@maniek41:

na zdrowy rozsądek nie ma powodów, aby przez criteria było inaczej niż JPQL
A że nie wszystko tam zawsze jest tak optymalne, jak by się marzyło ...

maniek41 napisał(a):

//Odpytanie leci w osobnym selekcie //zamiast z left join

bez realnego kodu odpowiedź daremna

Czyli przy Criteria oraz JPQL adnotacje nie sa uwzgledniane i np fetch join trzeba jawnie wywolac przy tworzeniu zapytania. O to wlasnie pytalem ;)

M4
  • Rejestracja:ponad 4 lata
  • Ostatnio:dzień
  • Postów:50
0

Przykładowa implementacja

Klasa User:

Kopiuj
@Entity
@Table(name = "user")
public class User implements Serializable {

    private static final long serialVersionUID = 1L;

    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "user_seq")
    @SequenceGenerator(name = "user_seq", allocationSize = 1)
    private Long id;

    @Column(name="login")
    private String login;

    @Column(name="password")
    private String password;

    @ManyToOne(fetch = FetchType.EAGER)
    private Address address;

    getters...
    setters...
}

Klasa Address:

Kopiuj
@Entity
@Table(name = "address")
public class Address implements Serializable {

    private static final long serialVersionUID = 1L;

    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "address_seq")
    @SequenceGenerator(name = "address_seq", allocationSize = 1)
    private Long id;

    @Column(name="street")
    private String street;

    @Column(name="city")
    private String city;

    @Column(name="zip_code")
    private String zipCode;

    getters...
    setters...
}

Użycie Criteria:

Kopiuj
CriteriaQuery cq = cb.createQuery(User.class);
Root<User> from = cq.from(User.class);
cq.select(from);
TypedQuery q = entityManager.createQuery(cq);
List<User> users = q.getResultList();

q.getResultList(); generuje dodatkowe zapytania o Address da każdego User z osobna (czyli problem n+1 zapytań)

edytowany 5x, ostatnio: maniek41
B9
  • Rejestracja:ponad 7 lat
  • Ostatnio:około 9 godzin
  • Postów:65
1

Użyj fetch joina. Wpisz w google criteria query fetch join n+1 i będzie pełno odpowiedzi.

M4
  • Rejestracja:ponad 4 lata
  • Ostatnio:dzień
  • Postów:50
0

Wiem ze mozna jawnie w criteria to wymusic, ale chodzi mi o fakt ze bez tego to criteria nie bierze domyslnie adnotacji i nie zrobi joina automatycznie?

B9
Spróbuj dać relacje zwrotną. Tak rzucony pomysł. Ogolnie jestem za JPQL, fetch join,ew. entity graph. Po co sobie utrudniać.
ZD
  • Rejestracja:około 3 lata
  • Ostatnio:ponad rok
  • Postów:2310
0
maniek41 napisał(a):

Wiem ze mozna jawnie w criteria to wymusic, ale chodzi mi o fakt ze bez tego to criteria nie bierze domyslnie adnotacji i nie zrobi joina automatycznie?

A spóbowaleś choć raz nie criteriami, a JPQL ?
Bo ja wierzę, że źle lokujesz problem ...
(tak prywatnie obstawiam)


If you put a million monkeys at a million keyboards, one of them will eventually write a Java program - the rest of them will write Perl
edytowany 1x, ostatnio: ZrobieDobrze
IV
  • Rejestracja:ponad 4 lata
  • Ostatnio:3 miesiące
  • Postów:30
0
maniek41 napisał(a):

Wiem ze mozna jawnie w criteria to wymusic, ale chodzi mi o fakt ze bez tego to criteria nie bierze domyslnie adnotacji i nie zrobi joina automatycznie?

Nie, domyślnie nie bierze, i jest ku temu powód.

Po pierwsze parametr FetchType o wartościach EAGER oraz LAZY mówi o tym, czy dane zostaną załadowane teraz czy później podczas próby ich dostępu w obrębie tej samej transakcji. Ten parametr nie mówi nic w jaki sposób. Wyobraźmy sobie sytuację, że jakiś programista w każdej relacji ustawił FetchType na EAGER oraz że to powoduje budowanie joina w zapytaniu to jeśliby doszłoby do cyklicznej relacji to zapytanie nigdy by nie skończyłoby się budować.

Po drugie Hibernate ma coś takiego jak cache transakcji dzięki któremu nie musi biegać po obiekty do bazy danych w obrębie tej samej transakcji, przykład: gdybyś najpierw wybrał zapytaniem wszystkie adresy dla danego usera i zignorowałbyś wynik zapytania to i tak trafią one do cache, następnie wybierając usera zobaczyłbyś, że nie ma już zapytań do tabeli z adresami i nie ma już problemu n+1, ponieważ te adresy są już w cache. Gdyby hibernate zawsze joinowałby to sprawiłoby, że musiałby przy każdym zapytaniu taki cache czyścić, bo join wyciągnąłby nowszą wersję adresu. Wtedy taki cache byłby bezsensowny.

Po trzecie jeśli używasz hibernate to masz coś takiego jak FetchMode, to on określa w jaki sposób dane są załadowane. Jeśli używasz jpa to możesz użyć entity graph, on pomaga przekazać sugestie w jaki sposób chcemy dane zaciągać z bazy danych.

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.