ZApis querry jako Criteria

Witam,

Zacząłem przepisywać query na criteria, ponieważ zaczeły mi sie mnoćyć selecty.
ZA każdą pomoc, wskazówkę będę bardzo wdzięczny.

Query query = entityManager.createQuery("From
GPSPositions gps WHERE gps.user <> 0 AND gps.id IN (SELECT max(gps2.id) from
GPSPositions gps2 group by gps2.user )");
List<GPSPositions> lista = query.getResultList();
return lista;

Moja prawie Criteria :

CriteriaBuilder builder = entityManager.getCriteriaBuilder();
CriteriaQuery<GPSPositions> criteria = builder.createQuery(GPSPositions.class);
Subquery<GPSPositions> subcq = criteria.subquery(GPSPositions.class);
Root<GPSPositions> data = subcq.from(GPSPositions.class);
criteria.select(from.get(builder.max(GPSPositions.user));
criteria.groupBy(from.get(GPSPositions.user));
TypedQuery<GPSPositions> query = entityManager.createQuery(criteria);
return query.getResultList();	

Chłopie co Ty robisz? Po co ? Jeśli już to być z criteria szedł w strone HQL jako bardziej czytelnego, wyrazistego zapisu

Szczery napisał(a):

Chłopie co Ty robisz? Po co ? Jeśli już to być z criteria szedł w strone HQL jako bardziej czytelnego, wyrazistego zapisu

Nie wiem czy dobrze myślę, ale jak użyję Criterii, to wtedy będę miał jedno zapytanie a na chwilę obecna dla 4 użytkowników(SELECT max(gps2.id) from
GPSPositions gps2 group by gps2.user) mam 5 zapytań.

lol niby dlaczego? kryteria są fajne do budowania (takie spring data specifications) , ale jakaś mniejsza ilośc zapytań? pierwsze słysze

Tak wyglądą mój jeden select :

INFO:   Hibernate: select gpspositio0_.PO_ID as PO_ID1_0_,
gpspositio0_.PO_CZAS_BAZY as PO_CZAS_BAZY2_0_,
gpspositio0_.PO_GEO_DLUGOSC as PO_GEO_DLUGOSC3_0_, 
gpspositio0_.PO_GEO_SZEROKOSC as PO_GEO_SZEROKOSC4_0_,
gpspositio0_.PO_USER_ID as PO_USER_ID5_0_ from POZYCJE_GPS gpspositio0_ where gpspositio0_.PO_USER_ID<>0 and (gpspositio0_.PO_ID
in (select max(gpspositio1_.PO_ID) from POZYCJE_GPS gpspositio1_ group by gpspositio1_.PO_USER_ID))

INFO:   Hibernate: select users0_.US_ID as US_ID1_1_0_,users0_.US_IMIE as US_IMIE2_1_0_, users0_.US_LOGIN as US_LOGIN3_1_0_, users0_.US_NAZWISKO as US_NAZWISKO4_1_0_, users0_.US_TELEFON as US_TELEFON5_1_0_ from USERS users0_ where users0_.US_ID=?
INFO:   Hibernate: select users0_.US_ID as US_ID1_1_0_, users0_.US_IMIE as US_IMIE2_1_0_, users0_.US_LOGIN as US_LOGIN3_1_0_, users0_.US_NAZWISKO as US_NAZWISKO4_1_0_, users0_.US_TELEFON as US_TELEFON5_1_0_ from USERS users0_ where users0_.US_ID=?
INFO:   Hibernate: select users0_.US_ID as US_ID1_1_0_,users0_.US_IMIE as US_IMIE2_1_0_, users0_.US_LOGIN as US_LOGIN3_1_0_, users0_.US_NAZWISKO as US_NAZWISKO4_1_0_, users0_.US_TELEFON asUS_TELEFON5_1_0_ from USERS users0_ where users0_.US_ID=?
...( w zaleznosci od liczy użytkowników)

Może ktos ma jakiś pomysł jak to zoptymalizować? ,

Jeżeli zapytanie jest niezmienne, to używaj query. Buildera używaj tylko jeżeli w trakcie pisania aplikacji nie znasz ostatecznej postaci zapytania. A nie znasz tej postaci właściwie tylko gdy robisz wyszukanie po wielu polach. Jeżeli otworzysz pierwszy lepszy sklep internetowy i masz filtrowanie po kilku polach, np. rozmiar ekranu monitora, producent, cena maksymalna etc, to nie wiesz jak do końca ma wyglądać where. To jest miejsce na użycie buildera.

Z drugiej strony zapomnij o criteria api. Ktoś musiał brać bardzo dużo narkotyków podczas jego projektowania. Musiałem pisać w nim dość dużo kodu i nawet na końcu nie mogłem robić tego bez dokumentacji. To chyba nie tak powinno wyglądać. Jako zamiennik proponuję QueryDSL. Ładne, czytelne i przede wszystkim intuicyjne api.