Paginazione con criteri in letargo e fetchmode.Join

Question

Ho due tavoli, "giocatori" e "oggetti". I giocatori hanno un elenco di articoli. Voglio recuperare i giocatori e tutti i loro oggetti, usando impaginazione. Voglio paginare in base ai giocatori e senza riguardo a quanti elementi ci siano.

Quindi faccio qualcosa di simile:

Criteria c = session.createCriteria(Players.class).setFetchMode("items", FetchMode.JOIN);
c.addOrder(Order.asc("playerID"));
c.setFirstResult(0);
c.setMaxResults(25);
List<Player> players = c.list();

Questo mi darà i primi 25 giocatori o mi darà i primi 25 articoli (raggruppati dai giocatori)? Mi chiedo se questo comportamento non è definito come sarebbe per le query JPA o se forse c'è una risposta garantita.

Indipendentemente da ciò, quali sono le domande dei criteri che mi darebbero i primi 25 giocatori o le prime 25 combinazioni di elementi giocatori (ordinati per ID giocatore, allora ID articolo)?

Answer 1

Abbastanza sicuro, ma non al 100%, farà quanto segue:

Si unirà ai giocatori e agli oggetti, ordina da PlayerID e prenderà i primi 25 risultati, tutti in una query SQL. Da questi dati, crea giocatori e oggetti, il che si tradurrà in una quantità arbitraria di giocatori (meno o uguale di 25) con un totale di 25 articoli. Può succedere che l'ultimo giocatore non ottenga tutti gli oggetti.

Per ottenere 25 giocatori, evita FetchMode.JOIN (Per evitare il problema N+1, utilizzare la dimensione batch nel file di mappatura):

List<Player> first25Players = session
  .createCriteria(Players.class)
  .addOrder(Order.asc("playerID"))
  .setMaxResults(25)
  .list();

Per ottenere 25 articoli, iniziare la query per articolo, non il giocatore.

List<Item> first25Items = session
  .createCriteria(Item.class)
  .addOrder(Order.asc("player")) // assuming that player is available
  .setMaxResults(25)
  .list();

Se non c'è navigazione dall'elemento al giocatore, puoi aggiungerne uno.

Answer 2

Dalle FAQ di "Problemi avanzati" per Hibernate:

http://community.jboss.org/wiki/Hibernatefaq-advancedProbles

Dovrebbe anche essere ovvio perché le operazioni "limite" basate su righe di ResultSet, come SetFirsTresult (5) e SetMaxResults (10) non funzionano con questo tipo di query di recupero ansiose. Se si limita il set di risultati a un determinato numero di righe, si tagliano i dati in modo casuale. Un giorno in letargo potrebbe essere abbastanza intelligente da sapere che se si chiama setFirStresult () o setMaxResults () non dovrebbe usare un join, ma una seconda selezione SQL. Provalo, la tua versione di Hibernate potrebbe essere già abbastanza intelligente. In caso contrario, scrivi due query, una per limitare le cose, l'altra per impazienza.

In altre parole, Hibernate non lo supporta. Se eri più intelligente e sapevi come è stato implementato Hibernate, avrebbe dovuto essere ovvio che SetFirsTresult e SetMaxResults non fanno nulla di remoto come la paginazione in tutti i casi. Era così ovvio che non ha bisogno di documentare.