Adnotacje a criteria query

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:

@Entity
@Table(name="user")
public class User {
...
//Odpytanie leci w osobnym selekcie //zamiast z left join
@ManyToOne
private Address address;
...
}
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

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 ;)

0

Przykładowa implementacja

Klasa User:

@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:

@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:

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ń)

1

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

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?

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)

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.

1 użytkowników online, w tym zalogowanych: 0, gości: 1