Mongoid 5 में निर्बाध माइग्रेशन: अद्यतन ड्राइवर कॉन्फ़िगरेशन और सर्वोत्तम अभ्यास

विकास कॉन्फ़िगरेशन

Mongoid 5 में अपग्रेड करने के बाद अपने Rails ऐप को शुरू करते समय आप सबसे पहले जिस चीज़ का सामना करेंगे, वह आपके डेटाबेस कॉन्फ़िगरेशन के गलत होने के बारे में एक त्रुटि है।

फिक्स आसान है, बस sessions को clients में बदलें:

development:
  clients:
    default:
      database: appsignal_development
      hosts:
        - localhost:27017

ड्राइवर परिवर्तन

हमारे कोडबेस में हम ड्राइवर पर "ड्रॉप डाउन" करते हैं ताकि moped/mongo-ruby-driver पर सीधे क्वेरी निष्पादित की जा सके, Mongoid का उपयोग करने के बजाय, उदाहरण के लिए प्रत्येक खाते के लिए संग्रह बनाने के लिए। यहां आपको session को client में बदलने की भी आवश्यकता होगी। एक और परिवर्तन यह है कि read अब सीधे मान के बजाय :mode कुंजी के साथ एक हैश की अपेक्षा करता है:

 def create_log_entry_collection
   Mongoid
     .client('default') # हुआ करता था `.session('default')`
     .with(:read => {:mode => :primary}) # हुआ करता था `read: => :primary`
     .database
     .command(:create => 'foo')
 end

Moped में एक insert मेथड है जो या तो एक सिंगल डॉक्यूमेंट या डॉक्यूमेंट्स की एक सरणी स्वीकार करता है। नया mongo-ruby-driver दो अलग-अलग मेथड के साथ आता है, और आपको उस मेथड को चुनना चाहिए जो इस बात पर निर्भर करता है कि आप कितने डॉक्यूमेंट्स डालना चाहते हैं:

# Before
Mongoid.client('default')['foo'].insert(document)
Mongoid.client('default')['foo'].insert([document, document])

# After
Mongoid.client('default')['foo'].insert_one(document)
Mongoid.client('default')['foo'].insert_many([document, document])

क्रम की कमी

नए ड्राइवर के साथ सबसे बड़े परिवर्तनों में से एक यह है कि डॉक्यूमेंट्स अब डिफ़ॉल्ट रूप से _id पर क्रमबद्ध नहीं होते हैं।

जब कोई सॉर्टिंग विकल्प प्रदान नहीं किया गया हो तो First और last अब _id सॉर्ट नहीं जोड़ते। यह गारंटी देने के लिए कि कोई डॉक्यूमेंट पहला या अंतिम है, इसमें अब एक स्पष्ट सॉर्ट होना चाहिए।

इसका मतलब है कि जहां भी आप क्रम पर भरोसा करते हैं (.first, .last) आपको क्वेरी को स्पष्ट रूप से _id द्वारा क्रमबद्ध करने की आवश्यकता है:

# Before
expect( User.first.name ).to eq 'bob'
expect( User.last.name ).to eq 'kelso'

# After
expect( User.asc('_id').first.name ).to eq 'bob'
expect( User.asc('_id').last.name ).to eq 'kelso' 

यह सुनिश्चित करने के लिए कि हमारा कोड पहले की तरह व्यवहार करता है, हमने एक कंसर्न बनाया जो एक डिफ़ॉल्ट स्कोप जोड़ता है जो _id द्वारा क्रमबद्ध करता है:

# concerns/ordered_by_id_asc.rb
module OrderedByIdAsc
  extend ActiveSupport::Concern
  included do
    default_scope -> { asc('_id') }
  end
end

# models/account.rb
class Account
  include Mongoid::Document
  include Mongoid::Timestamps
  include OrderedByIdAsc
end

FindAndModify

Find_and_modify हटा दिया गया है। इसके बजाय अब आपके पास चुनने के लिए 3 मेथड हैं:

• find_one_and_update
• find_one_and_replace (सुविधा मेथड, find_one_and_update को कॉल करता है)
• find_one_and_delete

ExpireAfterSeconds

अधिक अस्पष्ट परिवर्तनों में से एक TTL इंडेक्स बनाने का तरीका है। हम ग्राहक डेटा को उनकी योजना के आधार पर स्वचालित रूप से शुद्ध करने के लिए TTL इंडेक्स का उपयोग करते हैं (उदाहरण के लिए 7 दिनों के बाद, या एक महीने के बाद)।

इंडेक्स पर विकल्प को expire_after_seconds कहा जाता था, लेकिन इसका नाम बदलकर expire_after कर दिया गया है:

# Before
collection.indexes.create_one(
  {:time => 1},
  {:expire_after_seconds => ttl}
)

# After:
collection.indexes.create_one(
  {:time => 1},
  {:expire_after => ttl}
)

स्टेजिंग/प्रोडक्शन कॉन्फ़िगरेशन परिवर्तन

जहां विकास में हमें केवल sessions को clients में बदलने की आवश्यकता थी, वहीं हमारे स्टेजिंग/प्रोडक्शन कॉन्फ़िगरेशन को बहुत अधिक काम की आवश्यकता थी:

# Before
staging:
  sessions:
    default:
      database: appsignal_main
      username: <%= ENV['MONGOID_USERNAME'] %>
      password: <%= ENV['MONGOID_PASSWORD'] %>
      hosts:
        - mongo1.staging:27017
        - mongo2.staging:27017
        - mongo3.staging:27017
      options:
        read: :primary
        pool_size: {{ mongoid_pool_size }}
        ssl:
          ca_file: /etc/ssl/certs/root_ca.crt
          client_cert: /app/shared/config/mongodb_app.crt
          client_key: /app/shared/config/mongodb_app.key

# After
staging:
  clients:
    default:
      database: appsignal_main
      hosts:
        - mongo1.staging:27017
        - mongo2.staging:27017
        - mongo3.staging:27017
      options:
        user: <%= ENV['MONGOID_USERNAME'] %>
        password: <%= ENV['MONGOID_PASSWORD'] %>
        read:
          mode: :primary
        max_pool_size: {{ mongoid_pool_size }}
        ssl: true
        ssl_ca_cert: /etc/ssl/certs/root_ca.crt
        ssl_cert: /app/shared/config/mongodb_app.crt
        ssl_key: /app/shared/config/mongodb_app.key
        replica_set: staging

• username का नाम बदलकर user कर दिया गया है और options में ले जाया गया है
• password को options में ले जाया गया है
• read अब mode नामक एक नेस्टेड कुंजी की अपेक्षा करता है
• SSL अब एक नेस्टेड हैश नहीं है, बल्कि options के तहत सेट है
• कॉन्फ़िगरेशन के लिए एक replica_set कुंजी की आवश्यकता होती है यदि सेटअप एक replicaset है

अपग्रेड दस्तावेज़ कहता है कि MongoDB 2.4 और 2.6 :plain ऑथ का उपयोग करते हैं, लेकिन हमें सेटअप को काम करने के लिए auth_mech कुंजी को पूरी तरह से हटाने की आवश्यकता थी।

निष्कर्ष

हालांकि यह काफी व्यापक सूची है, हमने अपग्रेड को अपेक्षाकृत दर्द रहित पाया और नया ड्राइवर पुराने Moped ड्राइवर की तुलना में बहुत अधिक ठोस लगता है।