La chiave per risolvere questo problema è capire che l'utilizzo diretto di Mongoid
metodi quando il session_store della tua applicazione Rails 3 è impostato su mongoid_store non consentirebbe mai questo tipo di interazione diretta con il database.
Quindi, invece, utilizzando Mongoid solo per la connessione di base al database ma poi effettivamente interagendo con il Moto
core di Mongoid direttamente a livello operativo del driver, la stessa funzionalità può essere raggiunta con facilità! Ecco il rake Mongoid/Moped compito che mi è venuto in mente che funziona abbastanza bene:
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 connessione viene impostata tramite db = Mongoid::Sessions.default e la magia avviene nella linea:
db[:sessions].where('updated_at' => { '$lt' => stale_window.days.ago }).sort(updated_at: 1).no_timeout.remove_all
Ho impostato una stale_window variabile in modo da poter regolare facilmente l'intervallo di questa attività; imposta il valore DB e la descrizione. Per usarlo lo eseguo in questo modo dal percorso della codebase:
RAILS_ENV=production bundle exec rake sessions:cleanup
E ovviamente basta cambiare il RAILS_ENV valore che corrisponda all'ambiente in cui si desidera che questa attività agisca; come staging , development o qualsiasi altra cosa tu possa chiamare il tuo ambiente. Dopo aver eseguito quel rake task, le sessions la tabella di raccolta viene ridotta a qualcosa di più realistico con l'utilizzo nel mondo reale e la dimensione complessiva del database è più ragionevole da gestire.
