इसे हल करने की कुंजी यह समझना है कि डायरेक्ट Mongoid
का उपयोग करना तरीके जब आपके रेल 3 एप्लिकेशन का session_store mongoid_store . पर सेट है इस तरह के प्रत्यक्ष डेटाबेस इंटरैक्शन को कभी नहीं होने देंगे।
तो इसके बजाय, केवल मूल डेटाबेस कनेक्शन के लिए 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 संग्रह तालिका वास्तविक दुनिया के उपयोग के साथ कुछ अधिक यथार्थवादी हो जाती है और समग्र डेटाबेस आकार से निपटने के लिए अधिक उचित है।
