La clave para resolver esto es comprender que el uso directo de Mongoid
cuando el session_store de su aplicación Rails 3 está establecido en mongoid_store nunca permitiría que sucediera este tipo de interacción directa con la base de datos.
Entonces, en su lugar, usando Mongoid solo para la conexión básica de la base de datos pero luego interactuando con el Moped
core de Mongoid directamente en un nivel de operación del controlador, ¡la misma funcionalidad se puede lograr con facilidad! Aquí está el rake Mongoid/Moped tarea que se me ocurrió que funciona bastante bien:
namespace :sessions do
stale_window = 7
desc "Clear stale DB sessions older than #{ stale_window } days."
task :cleanup => :environment do
db = Mongoid::Sessions.default
begin
db[:sessions].where('updated_at' => { '$lt' => stale_window.days.ago }).sort(updated_at: 1).no_timeout.remove_all
rescue Moped::Errors::SocketError => e
# Rescue here if needed. If not, the screwed up process dies silently.
end
end
end
La conexión se establece a través de db = Mongoid::Sessions.default y la magia sucede en la línea:
db[:sessions].where('updated_at' => { '$lt' => stale_window.days.ago }).sort(updated_at: 1).no_timeout.remove_all
He configurado una stale_window variable para que pueda ajustar fácilmente el rango de esta tarea; establece el valor DB así como la descripción. Para usarlo, lo ejecuto así desde la ruta del código base:
RAILS_ENV=production bundle exec rake sessions:cleanup
Y, por supuesto, simplemente cambie el RAILS_ENV valor para que coincida con el entorno en el que desea que actúe esta tarea; como staging , development o cualquier otra cosa que pueda llamar a su entorno. Después de ejecutar ese rake tarea, las sessions la tabla de colección se reduce a algo más realista con el uso del mundo real y el tamaño general de la base de datos es más razonable de manejar.
