Utilizzo di will_paginate senza: total_entries per migliorare una query lunga

Question

Ho un'implementazione corrente di will_paginate che utilizza il metodo paginate_by_sql per creare la raccolta da impaginare. Abbiamo una query personalizzata per total_entries che è molto complicata e carica molto il nostro DB. Pertanto vorremmo eliminare del tutto le voci dalla paginazione.

In altre parole, invece della tipica visualizzazione impaginata di "precedente 1 [2] 3 4 5 successivo", vorremmo semplicemente solo un pulsante "successivo - precedente". Ma dobbiamo sapere alcune cose.

1. Visualizziamo il link precedente? Ciò si verificherebbe ovviamente solo se i record esistenti prima di quelli visualizzati nella selezione corrente
2. Visualizziamo il prossimo link? Questo non verrà visualizzato se viene visualizzato l'ultimo record della raccolta

Dal

È stato utile?

Invia

Soluzione

Ci sono molte occasioni in cui will_paginate fa un lavoro davvero terribile nel calcolare il numero di voci, specialmente se ci sono join coinvolti che confondono il generatore di conteggio SQL.

Se tutto ciò di cui hai bisogno è un semplice metodo precedente / successivo, tutto ciò che devi fare è tentare di recuperare N + 1 voci dal database e se ottieni solo N o meno di quanto sei nell'ultima pagina.

Ad esempio:

per_page = 10
page = 2

@entries = Thing.with_some_scope.find(:all, :limit => per_page + 1, :offset => (page - 1) * per_page)

@next_page = @entries.slice!(per_page, 1)
@prev_page = page > 1

Puoi incapsularlo facilmente in alcuni moduli che possono essere inclusi nei vari modelli che lo richiedono o creare un'estensione del controller.

Ho scoperto che funziona molto meglio del metodo will_paginate predefinito.

L'unico problema di prestazioni è una limitazione di MySQL che può essere un problema a seconda delle dimensioni delle tabelle.

Per qualsiasi motivo, la quantità di tempo necessaria per eseguire una query con un piccolo LIMIT in MySQL è proporzionale all'Offset. In effetti, il motore di database legge tutte le righe che portano al particolare valore di offset, quindi restituisce le successive righe di numero LIMIT, non saltando avanti come ci si aspetterebbe.

Per insiemi di dati di grandi dimensioni, in cui si hanno valori OFFSET nell'intervallo 100.000, è possibile che le prestazioni diminuiscano in modo significativo. Ciò che si manifesterà è che il caricamento della pagina 1 è molto veloce, la pagina 1000 è piuttosto lenta, ma la pagina 2000 è estremamente lenta.

Answer 1

Ci sono molte occasioni in cui will_paginate fa un lavoro davvero terribile nel calcolare il numero di voci, specialmente se ci sono join coinvolti che confondono il generatore di conteggio SQL.

Se tutto ciò di cui hai bisogno è un semplice metodo precedente / successivo, tutto ciò che devi fare è tentare di recuperare N + 1 voci dal database e se ottieni solo N o meno di quanto sei nell'ultima pagina.

Ad esempio:

per_page = 10
page = 2

@entries = Thing.with_some_scope.find(:all, :limit => per_page + 1, :offset => (page - 1) * per_page)

@next_page = @entries.slice!(per_page, 1)
@prev_page = page > 1

Puoi incapsularlo facilmente in alcuni moduli che possono essere inclusi nei vari modelli che lo richiedono o creare un'estensione del controller.

Ho scoperto che funziona molto meglio del metodo will_paginate predefinito.

L'unico problema di prestazioni è una limitazione di MySQL che può essere un problema a seconda delle dimensioni delle tabelle.

Per qualsiasi motivo, la quantità di tempo necessaria per eseguire una query con un piccolo LIMIT in MySQL è proporzionale all'Offset. In effetti, il motore di database legge tutte le righe che portano al particolare valore di offset, quindi restituisce le successive righe di numero LIMIT, non saltando avanti come ci si aspetterebbe.

Per insiemi di dati di grandi dimensioni, in cui si hanno valori OFFSET nell'intervallo 100.000, è possibile che le prestazioni diminuiscano in modo significativo. Ciò che si manifesterà è che il caricamento della pagina 1 è molto veloce, la pagina 1000 è piuttosto lenta, ma la pagina 2000 è estremamente lenta.