La clé pour résoudre ce problème est de comprendre que l'utilisation directe de Mongoid
méthodes lorsque le session_store de votre application Rails 3 est défini sur mongoid_store ne permettrait jamais ce type d'interaction directe avec la base de données.
Donc, à la place, en utilisant Mongoid uniquement pour la connexion de base à la base de données, mais en interagissant ensuite avec le Moped
noyau de Mongoid directement au niveau de l'opération du pilote, la même fonctionnalité peut être obtenue facilement ! Voici le rake Mongoid/Moped tâche que j'ai trouvée qui fonctionne plutôt 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 connexion est définie via db = Mongoid::Sessions.default et la magie opère dans la ligne :
db[:sessions].where('updated_at' => { '$lt' => stale_window.days.ago }).sort(updated_at: 1).no_timeout.remove_all
J'ai défini un stale_window variable afin que je puisse facilement ajuster la portée de cette tâche ; définit la valeur DB ainsi que la description. Pour l'utiliser, je le lance comme ceci à partir du chemin de la base de code :
RAILS_ENV=production bundle exec rake sessions:cleanup
Et bien sûr il suffit de changer le RAILS_ENV valeur correspondant à l'environnement sur lequel vous souhaitez que cette tâche agisse ; comme staging , development ou tout autre nom que vous pourriez donner à votre environnement. Après avoir exécuté ce rake tâche, les sessions La table de collection est réduite à quelque chose de plus réaliste avec une utilisation réelle et la taille globale de la base de données est plus raisonnable à gérer.
