JPA - where in

0

Cześć,

Mam np. aukcje allegro.
Chciałbym z DB pobrać aukcje o id 1,2,3,4,5,6,7,8,9,10 i odpowiadające im opisy.

Czy i dlaczego, które rozwiązanie z punktu entity managera/DB jest lepsze:
1.

 
for(Int id : auctions) {
    results.put(id,get(Clazz.class,id);
}
 
res = executeNativeQuery('SELECT id,opis FROM aukcje where ID in auctions');
for(Object[] : res) {
 res.put(res[0],res[1]);
}
0

W pierwszym przypadku wykonujesz 10 zapytań do bazy, z czego każde wymaga odczytu danych z dysku. W drugim przypadku masz jedno zapytanie, które może być wykonane za pomocą jednokrotnego odczytu danych. Czy pytanie jest retoryczne?

0

Bardziej chodzi mi o mechanizmy JEE.
W pierwszym przypadku tak naprawdę robie find(Clazz.class,1), w drugim musze korzystac z nativeQuery.
Jedno obsluguje kesza, drugie pomija caly ten mechanizm.
Dodatkowo pozniej sam musze przerzucic te dane i poukladac.

0
  1. Nie wiem czy ci odpowiadać skoro zaraz znów możesz edytować posta i zmienić pytanie...
  2. Ale co ty za bzdury opowiadasz? Jakie znów "musze korzystać z nativeQuery"? To że nie umiesz korzystać z danej technologii to nie znaczy że jest ona zła. Możesz to zrobić za pomocą JPQL, mozesz za pomocą Criteria API. Oba rozwiązania będą lepsze niż to co napisałeś. Może zamiast zadawać głupie pytania po prostu przeczytasz tutorial JPA?
  3. Nie zmienia to nadal faktu że pobranie rekordów na raz jest lepsze niż generowanie N zapytań. Szczególnie że sądząc po twoim "kunszcie" programistycznym zapewne masz gdzieś w tych swoich encjach kolekcje lazy i dla każdej encji robisz klasyczne n+1 selectów.
0

Wskaż miejsce w tutorialu JPA pokazujące różnice w omawianym zagadnieniu.
Chodzi o performance między nativeQuery i chociażby namedQuery w ujęciu collection-valued parameter.
Bo jak na razie starasz się udowodnić, że nie znam JPA. ;)

Jeśli tak doskonale znasz JPA, to dlaczego sądzisz, że hibernate dla każdej kolekcji robi osobne query? ;-)

0
  1. W takim razie ja w ogóle nie rozumiem jaki jest twój problem. Czy twoje pytanie brzmi: czy JPA przechowuje w cache encje pobrane za pomocą nativeQuery? Bo z twojego posta wcale to nie wynika... Twierdzisz ze musisz użyć nativeQuery, co jest bzdurą bo równie dobrze mógłbyś wybrać z bazy całe encje za pomocą JPQL / Criteria w jednym zapytaniu a nie w N zapytaniach.
  2. Hibernate nie wykonuje osobnego query dla każdej kolekcji jeśli zrobisz to z głową. Wielu ludzi nie robi i w ramach "optymalizacji" oznacza sobie kolekcje jako LAZY (bo przecież nie zawsze jej potrzebują to nie trzeba jej zawsze pobierać z bazy). Efekt jest taki że pobranie encji z taką kolekcją a potem odwołanie się do niej powoduje:
  • lazy initialization exception jeśli sesja jest już zamknięta (przypadek szczęśliwy bo od razu wiadomo co ktoś zepsuł)
  • dociąganie elementów kolekcji przez JPA jeśli sesja jeszcze jest otwarta, co niestety skutkuje wygenerowanie n zapytań, po jednym dla każdego elementu kolekcji.
    Bo nie każdy wie że w zapytaniu można dopisać fetch join dla kolekcji która jest lazy i pobrać wszystko jeśli jest potrzebne.

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