Usar will_paginate sin: total_entries para mejorar una consulta larga

Question

Tengo una implementación actual de will_paginate que usa el método paginate_by_sql para construir la colección que se va a paginar. Tenemos una consulta personalizada para total_entries que es muy complicada y pone una gran carga en nuestra base de datos. Por lo tanto, nos gustaría cortar total_entries de la paginación por completo.

En otras palabras, en lugar de la visualización típica de paginación de 'anterior 1 [2] 3 4 5 siguiente', simplemente nos gustaría un botón 'siguiente - anterior' solamente. Pero necesitamos saber algunas cosas.

1. ¿Mostramos el enlace anterior? Por supuesto, esto solo ocurriría si los registros existentes antes de los que se muestran en la selección actual
2. ¿Mostramos el siguiente enlace? Esto no se mostrará si se muestra el último registro de la colección

Del

¿Fue útil?

Enviar

Solución

Hay muchas ocasiones en las que will_paginate realiza un trabajo realmente horrible al calcular el número de entradas, especialmente si hay uniones involucradas que confunden el generador SQL de conteo.

Si todo lo que necesita es un método anterior / siguiente simple, entonces todo lo que necesita hacer es intentar recuperar entradas N + 1 de la base de datos, y si solo obtiene N o menos de lo que está en la última página.

Por ejemplo:

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

Puede encapsular esto fácilmente en algún módulo que se puede incluir en los distintos modelos que lo requieren, o hacer una extensión de controlador.

He descubierto que esto funciona significativamente mejor que el método predeterminado will_paginate.

El único problema de rendimiento es una limitación de MySQL que puede ser un problema dependiendo del tamaño de sus tablas.

Por cualquier razón, la cantidad de tiempo que lleva realizar una consulta con un LÍMITE pequeño en MySQL es proporcional al OFFSET. En efecto, el motor de la base de datos lee todas las filas que conducen al valor de desplazamiento particular, luego devuelve las siguientes filas de LÍMITES, sin saltarse como se esperaría.

Para conjuntos de datos grandes, donde tiene valores de OFFSET en el rango de más de 100,000, puede encontrar que el rendimiento se degrada significativamente. Lo que se manifestará es que cargar la página 1 es muy rápido, la página 1000 es algo lenta, pero la página 2000 es extremadamente lenta.

Answer 1

Hay muchas ocasiones en las que will_paginate realiza un trabajo realmente horrible al calcular el número de entradas, especialmente si hay uniones involucradas que confunden el generador SQL de conteo.

Si todo lo que necesita es un método anterior / siguiente simple, entonces todo lo que necesita hacer es intentar recuperar entradas N + 1 de la base de datos, y si solo obtiene N o menos de lo que está en la última página.

Por ejemplo:

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

Puede encapsular esto fácilmente en algún módulo que se puede incluir en los distintos modelos que lo requieren, o hacer una extensión de controlador.

He descubierto que esto funciona significativamente mejor que el método predeterminado will_paginate.

El único problema de rendimiento es una limitación de MySQL que puede ser un problema dependiendo del tamaño de sus tablas.

Por cualquier razón, la cantidad de tiempo que lleva realizar una consulta con un LÍMITE pequeño en MySQL es proporcional al OFFSET. En efecto, el motor de la base de datos lee todas las filas que conducen al valor de desplazamiento particular, luego devuelve las siguientes filas de LÍMITES, sin saltarse como se esperaría.

Para conjuntos de datos grandes, donde tiene valores de OFFSET en el rango de más de 100,000, puede encontrar que el rendimiento se degrada significativamente. Lo que se manifestará es que cargar la página 1 es muy rápido, la página 1000 es algo lenta, pero la página 2000 es extremadamente lenta.