ruby-on-rails named-scope will-paginate

ruby on rails - will_paginate con named_scopes



ruby-on-rails named-scope (4)

Lowgain, la versión de Klew debería funcionar fuera de la caja. En tu versión deberías escribir:

User.scope.paginate :page => params[:page], :per_page => 10

Prefiero otro enfoque a la paginación. Permite hacer que el controlador sea más limpio y encapsula la paginación a nivel de modelo, por ejemplo:

class Property < ActiveRecord::Base named_scope :all_properties, lambda {{ :order => "name asc" }} def self.admin_properties(page = 1) self.all_properties.paginate(:page => page, :per_page => Settings.admin.per_page) end end

Y en un controlador de código bastante claro:

class Admin::PropertiesController < Admin::AdminController def index @properties = Property.admin_properties(params[:page]) end end

ps: Settings.admin.per_page - esta es la configuración de Searchlogic .

Estoy usando will_paginate para la paginación, que ha estado funcionando bien hasta ahora, excepto por esta única cosa.

Si intento paginar un alcance, por ejemplo

class User < ActiveRecord::Base named_scope :scope, lambda { etc } end User.scope.paginate({:page => params[:page], :per_page => 10})

Eso me dirá que paginar es un método indefinido. Prefiero no tener que usar una segunda solución solo para este ámbito, ¿hay algo que pueda hacer aquí?


Lowgain, no suena como si lo fueras, pero solo para asegurarte, en realidad no estás haciendo pruebas con un alcance llamado named_scope ¿no? Debido a que el alcance es un método existente y usarlo como su nombre de alcance causa un error (y un bucle infinito).

EDITAR:

¿Ocurre que named_scope incluya una cláusula de límite? Acabo de empezar a tener un problema similar. Tengo un modelo de respuesta que pertenece a un usuario, con un ámbito denominado algo así:

named_scope :top, lambda { |limit| { :limit => limit, :order => ''total_score DESC'' }}

Y estoy viendo resultados en la consola como esta:

?> u = User.find 1 ?> u.responses.length => 9 ?> u.responses.paginate(:page => 1, :per_page => 5).length => 5 ?> u.responses.top(3).length => 3 ?> u.responses.top(3).paginate(:page => 1, :per_page => 5).length => 5

¡Ay! ¿Cómo pueden mis 3 mejores páginas paginar para producir más de 3 filas? Por su ejemplo, probé su truco de encontrar (: todos) con resultados similares:

?> u.responses.top(3).find(:all).paginate(:page => 1, :per_page => 5).length => 3

Esto parece un error en named_scope, porque puedo eliminar a will_paginate de la imagen y hacer que se produzca un caos similar:

?> u.responses.top(3).length => 3 ?> u.responses.top(3).size => 9 <-- .size produces wrong answer ?> r = u.responses.top(3) ?> r.size => 3 <-- correct when result assigned to var

Hasta ahora, esto solo parece suceder cuando uso MySQL. Creo que leí otra publicación en donde alguien tenía un problema similar al usar .size con los resultados de AR y MySQL, y la solución era usar siempre .length en sus resultados de AR. He intentado modificar will_paginate para reemplazar todas las instancias de .size con .length, pero lamentablemente no fue tan simple, pero sospecho que este o un problema similar está afectando de alguna manera a will_paginate.

Por el momento, estoy usando tu truco de encontrar (: todos) para solucionar esto.


Tengo un named_scope definido así:

named_scope :look_for, lambda { |search| bla;bla;bla }

Yo lo llamo

Person.look_for(params[:search]).paginate :page => params[:page]

Y funciona. ¿Tal vez necesitas algún parámetro a tu alcance?


Una especie de solución extraña, pero

User.scope.find(:all).paginate :page => params[:page], :per_page => 10

¿trabajos?