Come gestire un ampio set di dati utilizzando i Data Reporter di Spring?

Question

Ho una tabella di grandi dimensioni a cui vorrei accedere tramite un archivio dati Spring.

Attualmente, sto cercando di estendere l'interfaccia PagingAndSortingRepository ma sembra che posso solo definire metodi che restituiscono liste, ad es .:

public interface MyRepository extends 
     PagingAndSortingRepository<MyEntity, Integer> 
{ 
    @Query(value="SELECT * ...") 
    List<MyEntity> myQuery(Pageable p); 
} 

D'altra parte, il metodo findAll() che viene fornito con PagingAndSortingRepository rendimenti un Iterable (e suppongo che i dati non siano caricati in memoria).

È possibile definire query personalizzate che restituiscono anche Iterable e/o non caricano tutti i dati in memoria in una sola volta?

Esistono alternative per la gestione di tavoli di grandi dimensioni?

Answer 1

Abbiamo la risposta di consulenza classica qui: dipende. Poiché l'implementazione del metodo è specifica del negozio, dipendiamo dall'API del negozio sottostante. In caso di JPA non è possibile fornire l'accesso allo streaming come ….getResultList() restituisce un List. Quindi esponiamo anche il al client, in quanto gli sviluppatori JPA potrebbero essere utilizzati per lavorare con gli elenchi. Quindi per JPA l'unica opzione è usare l'API di impaginazione.

Per un negozio come Neo4j supportiamo l'accesso allo streaming poiché i repository restituiscono Iterable sui metodi CRUD e sull'esecuzione dei metodi finder.

Answer 2

Il implementation di findAll() carica semplicemente l'intero elenco di tutte le entità in memoria. Il suo tipo di ritorno Iterable non implica che implementa una sorta di gestione del cursore a livello di database.

D'altra parte il tuo metodo personalizzato myQuery(Pageable) caricherà solo un valore di una pagina di entità, poiché l'implementazione generata rispetta il suo parametro Pageable. È possibile dichiarare il tipo di reso come Page o List. In quest'ultimo caso, si riceve comunque lo stesso numero (limitato) di entità, ma non i metadati che un Page porta in aggiunta.

Quindi, in pratica, hai fatto la cosa giusta per evitare di caricare tutte le entità in memoria nella tua query personalizzata.

Rivedere lo related documentation here.