これを解決するための鍵は、直接Mongoid
を使用することを理解することです。 Rails3アプリケーションのsession_store
の場合のメソッド mongoid_store
に設定されています この種の直接的なデータベースの相互作用が発生することは決してありません。
したがって、代わりに、基本的なデータベース接続のためだけにMongoidを使用し、実際にMoped
と対話します。 Mongoidのコアをドライバーの操作レベルで直接使用すると、同じ機能を簡単に実現できます。これがMongoid/Moped rake
です 私が思いついたタスクは非常にうまく機能します:
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
接続はdb = Mongoid::Sessions.default
を介して設定されます そして魔法は次の行で起こります:
db[:sessions].where('updated_at' => { '$lt' => stale_window.days.ago }).sort(updated_at: 1).no_timeout.remove_all
stale_window
を設定しました このタスクの範囲を簡単に調整できるように変数。 DB値と説明を設定します。これを使用するには、コードベースパスから次のように実行します。
RAILS_ENV=production bundle exec rake sessions:cleanup
そしてもちろん、RAILS_ENV
を変更するだけです このタスクが実行する環境に一致する値。 staging
など 、development
または、環境に名前を付けることができる他の名前を付けます。そのrake
を実行した後 タスク、sessions
コレクションテーブルは、実際の使用法でより現実的なものに整理され、データベース全体のサイズを処理するのがより合理的です。