Ключът към разрешаването на това е разбирането, че използването на директен Mongoid
методи, когато session_store
на вашето приложение Rails 3 е зададено на mongoid_store
никога няма да позволи да се случи този вид директно взаимодействие с база данни.
Вместо това, като използвате Mongoid само за основната връзка с базата данни, но след това действително взаимодействате с Moped
ядрото на Mongoid директно на ниво работа на драйвера, същата функционалност може да бъде постигната с лекота! Ето го rake
Mongoid/Moped задача, която измислих и работи доста добре:
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
таблицата за събиране се съкращава до нещо по-реалистично с използване в реалния свят и общият размер на базата данни е по-разумен за работа.