রেল মাইগ্রেশন ব্যবচ্ছেদ

আজকের পোস্টে, আমরা রেল মাইগ্রেশনের গভীরে ডুব দেব। আমরা মাইগ্রেশনকে বিভিন্ন অংশে ভেঙ্গে ফেলব, এবং প্রক্রিয়ায়, কীভাবে একটি কার্যকর মাইগ্রেশন লিখতে হয় তা শিখব। আমরা শিখব কিভাবে একাধিক ডাটাবেসের জন্য মাইগ্রেশন লিখতে হয়, সেইসাথে কীভাবে ব্যর্থ মাইগ্রেশন এবং রোলব্যাক করার কৌশলগুলি পরিচালনা করতে হয়।

পুরো পোস্টটি বোঝার জন্য, আপনাকে ডেটাবেস এবং রেল সম্পর্কে প্রাথমিক ধারণা থাকতে হবে।

মাইগ্রেশন 101

রেলে মাইগ্রেশন আমাদের একটি অ্যাপ্লিকেশনের জীবনকাল ধরে ডাটাবেস বিকশিত করার অনুমতি দেয়। মাইগ্রেশন আমাদেরকে একটি মার্জিত DSL প্রদান করে ডাটাবেসের অবস্থা পরিবর্তন করতে প্লেইন রুবি কোড লিখতে দেয়। আমাদের ডাটাবেস-নির্দিষ্ট এসকিউএল লিখতে হবে না যেহেতু মাইগ্রেশন ডাটাবেসকে ম্যানিপুলেট করার জন্য বিমূর্ততা প্রদান করে এবং দৃশ্যের পিছনে DSL-কে ডাটাবেস-নির্দিষ্ট SQL ক্যোয়ারীতে রূপান্তর করার জন্য নিট্টি-কঠোর বিবরণের যত্ন নেয়। মাইগ্রেশনগুলিও আমাদের পথের বাইরে চলে যায় এবং এই ধরনের প্রয়োজন দেখা দিলে ডাটাবেসে কাঁচা SQL কার্যকর করার উপায় প্রদান করে৷

একটি রেল ডেটাবেস মাইগ্রেশনে বিশ হাজার লিগ

আমরা মাইগ্রেশন ব্যবহার করে টেবিল তৈরি করতে পারি, কলাম যোগ করতে বা অপসারণ করতে পারি এবং কলামে সূচী যোগ করতে পারি।

প্রতিটি রেল অ্যাপের একটি বিশেষ ডিরেক্টরি রয়েছে—db/migrate —যেখানে সমস্ত স্থানান্তর সংরক্ষণ করা হয়।

আসুন একটি মাইগ্রেশন দিয়ে শুরু করি যা টেবিল events তৈরি করে আমাদের ডাটাবেসে।

$ rails g migration CreateEvents category:string

এই কমান্ডটি একটি টাইমস্ট্যাম্পড ফাইল তৈরি করে 20200405103635_create_events.rb db/migrate-এ ডিরেক্টরি ফাইলের বিষয়বস্তু নিম্নরূপ।

class CreateEvents < ActiveRecord::Migration[6.0]
  def change
    create_table :events do |t|
      t.string :category
 
      t.timestamps
    end
  end
end

আসুন এই মাইগ্রেশন ফাইলটি ভেঙে দেই।

• রেলস তৈরি করা প্রতিটি মাইগ্রেশন ফাইলের একটি টাইমস্ট্যাম্প থাকে যা ফাইলের নামে উপস্থিত থাকে। এই টাইমস্ট্যাম্পটি গুরুত্বপূর্ণ এবং একটি মাইগ্রেশন চলছে কিনা তা নিশ্চিত করতে রেল দ্বারা ব্যবহৃত হয়, আমরা পরে দেখব।
• মাইগ্রেশনে এমন একটি ক্লাস রয়েছে যা ActiveRecord::Migration[6.0] থেকে উত্তরাধিকারসূত্রে পাওয়া যায়। . যেহেতু আমি রেল 6 ব্যবহার করছি, মাইগ্রেশন সুপারক্লাসে রয়েছে [6.0] . আমি যদি Rails 5.2 ব্যবহার করতাম, তাহলে সুপারক্লাস হবে ActiveRecord::Migration[5.2] . পরে, আমরা আলোচনা করব কেন রেল সংস্করণ সুপারক্লাস নামের অংশ।
• মাইগ্রেশনের একটি পদ্ধতি আছে change যেটিতে DSL কোড রয়েছে যা ডাটাবেসকে ম্যানিপুলেট করে। এই ক্ষেত্রে, change পদ্ধতি একটি events তৈরি করছে একটি কলাম category সহ টেবিল string প্রকার .
• মাইগ্রেশন কোড t.timestamps ব্যবহার করে টাইমস্ট্যাম্প যোগ করতে created_at এবং updated_at events-এ টেবিল।

যখন এই মাইগ্রেশনটি rails db:migrate ব্যবহার করে চালানো হয় কমান্ড, এটি একটি events তৈরি করবে একটি category সহ টেবিল string ধরনের কলাম এবং টাইমস্ট্যাম্প কলাম created_at এবং updated_at .

ডাটাবেসের উপর নির্ভর করে প্রকৃত ডাটাবেস কলামের ধরন ভার্চার বা টেক্সট হবে।

মাইগ্রেশন টাইমস্ট্যাম্প এবং স্কিমা_মাইগ্রেশন টেবিলের গুরুত্ব

প্রতিবার rails g migration ব্যবহার করে একটি মাইগ্রেশন তৈরি করা হয় কমান্ড, রেলগুলি একটি অনন্য টাইমস্ট্যাম্প সহ মাইগ্রেশন ফাইল তৈরি করে। টাইমস্ট্যাম্পটি YYYYMMDDHHMMSS ফর্ম্যাটে রয়েছে .যখনই একটি মাইগ্রেশন চালানো হয়, রেলগুলি একটি অভ্যন্তরীণ সারণিতে মাইগ্রেশন টাইমস্ট্যাম্প সন্নিবেশিত করে schema_migrations . এই টেবিলটি রেল দ্বারা তৈরি করা হয় যখন আমরা আমাদের প্রথম মাইগ্রেশন চালাই। টেবিলে শুধুমাত্র version কলাম আছে , যা এর প্রাথমিক কীও। এটি schema_migrations এর গঠন টেবিল।

CREATE TABLE IF NOT EXISTS "schema_migrations" ("version" varchar NOT NULL PRIMARY KEY);

এখন যেহেতু আমরা events তৈরি করার জন্য মাইগ্রেশন চালিয়েছি টেবিল, চলুন দেখি রেল এই মাইগ্রেশনের অ্যাটাইমস্ট্যাম্প schema_migrations এ সংরক্ষণ করেছে কিনা। টেবিল।

sqlite> select * from schema_migrations;
20200405103635

যদি আমরা আবার মাইগ্রেশন চালাই, রেল প্রথমে চেক করবে যে schema_migrations-এ কোনো এন্ট্রি আছে কিনা মাইগ্রেশন ফাইলের টাইমস্ট্যাম্প সহ টেবিল, এবং যদি এই ধরনের কোনো এন্ট্রি না থাকে তবেই এটি চালান। এটি নিশ্চিত করে যে আমরা সময়ের সাথে সাথে ডাটাবেসে পরিবর্তনগুলি ক্রমবর্ধমানভাবে যুক্ত করতে পারি এবং একটি মাইগ্রেশন শুধুমাত্র একবার ডাটাবেসে চলবে৷

ডাটাবেস স্কিমা

আমরা যত বেশি মাইগ্রেশন চালাই, ডাটাবেস স্কিমা বিকশিত হতে থাকে। রেলগুলি db/schema.rb ফাইলে সাম্প্রতিকতম ডেটাবেস স্কিমা সংরক্ষণ করে . এই ফাইলটি হল অ্যাপ্লিকেশনের জীবনকাল ধরে আপনার ডাটাবেসের সমস্ত মাইগ্রেশনের রুবি প্রতিনিধিত্ব। এই ফাইলটির কারণে, আমাদের কোডবেসে মাইগ্রেশন ফাইলগুলি রাখার দরকার নেই। রেলগুলি dump করার কাজগুলি প্রদান করে৷ ডাটাবেস থেকে schema.rb-এ সর্বশেষ স্কিমা এবং load schema.rb থেকে একটি ডাটাবেসে স্কিমা . তাই পুরানো মাইগ্রেশনগুলি কোডবেস থেকে নিরাপদে মুছে ফেলা যেতে পারে। ডাটাবেসে স্কিমা লোড করাও আমরা যখনই অ্যাপ্লিকেশন সেট আপ করি তখন প্রতিটি মাইগ্রেশন চালানোর তুলনায় দ্রুততর হয়৷

রেল এসকিউএল ফরম্যাটে ডাটাবেস স্কিমা সংরক্ষণ করার একটি উপায়ও প্রদান করে। দুটি ফরম্যাটের তুলনা করার জন্য আমাদের কাছে ইতিমধ্যেই একটি নিবন্ধ রয়েছে। আপনি এখানে এটি সম্পর্কে আরও পড়তে পারেন।

মাইগ্রেশনে রেল সংস্করণ

আমাদের তৈরি করা প্রতিটি মাইগ্রেশনে সুপারক্লাসের অংশ হিসেবে রেল সংস্করণ থাকে। তাই একটি Rails 6 অ্যাপের দ্বারা তৈরি করা একটি মাইগ্রেশনে রয়েছে সুপারক্লাস ActiveRecord::Migration[6.0] যেখানে Rails 5.2 অ্যাপ দ্বারা উত্পন্ন মাইগ্রেশনে রয়েছে সুপারক্লাস ActiveRecord::Migration[5.2] . আপনার কাছে Rails 4.2 বা তার নিচের অ্যানল্ড অ্যাপ থাকলে, আপনি লক্ষ্য করবেন যে সুপারক্লাসের কোনো সংস্করণ নেই। সুপারক্লাসটি শুধুমাত্র ActiveRecord::Migration .

Rails সংস্করণটি Rails 5-এ মাইগ্রেশন সুপারক্লাসে যোগ করা হয়েছিল। এটি মূলত নিশ্চিত করে যে মাইগ্রেশনএপিআই রেলের পুরানো সংস্করণগুলির দ্বারা উত্পন্ন মাইগ্রেশনগুলিকে ভেঙে না দিয়ে সময়ের সাথে বিকশিত হতে পারে।

আসুন একটি events তৈরি করার জন্য একই স্থানান্তর দেখে এর গভীরে দেখি একটি Rails 4.2 অ্যাপে টেবিল।

class CreateEvents < ActiveRecord::Migration
  def change
    create_table :events do |t|
      t.string :category
 
      t.timestamps null: false
    end
  end
end

আমরা যদি events এর স্কিমা দেখি একটি Rails 6 মাইগ্রেশন দ্বারা উত্পন্ন টেবিল, আমরা দেখতে পাচ্ছি যে NOT NULL টাইমস্ট্যাম্প কলামের জন্য সীমাবদ্ধতা বিদ্যমান।

sqlite> .schema events
CREATE TABLE IF NOT EXISTS "events" ("id" integer PRIMARY KEY AUTOINCREMENT NOT NULL, "category" varchar, "created_at" datetime(6) NOT NULL, "updated_at" datetime(6) NOT NULL);

এর কারণ হল, Rails 5 থেকে শুরু করে, মাইগ্রেশন API স্বয়ংক্রিয়ভাবে একটি NOT NULL যোগ করে মাইগ্রেশন ফাইলে স্পষ্টভাবে যোগ করার প্রয়োজন ছাড়াই টাইমস্ট্যাম্প কলামগুলিতে সীমাবদ্ধতা। সুপারক্লাস নামের রেল সংস্করণটি নিশ্চিত করে যে মাইগ্রেশনটি রেল সংস্করণের মাইগ্রেশন API ব্যবহার করে যার জন্য মাইগ্রেশন তৈরি করা হয়েছিল। এটি রেলগুলিকে পুরানো মাইগ্রেশনগুলির সাথে পিছনের সামঞ্জস্য বজায় রাখার অনুমতি দেয়, একই সাথে মাইগ্রেশন এপিআই বিকশিত করে৷

ডাটাবেস স্কিমা পরিবর্তন করা

change পদ্ধতি একটি মাইগ্রেশন প্রাথমিক পদ্ধতি. যখন একটি মাইগ্রেশন চালানো হয়, তখন এটি change কল করে মেথড এবং এর ভিতরে কোড এক্সিকিউট করে।

create_table এর সাথে , রেলগুলি আরও একটি শক্তিশালী পদ্ধতি প্রদান করে—change_table .নাম থেকে বোঝা যায়, এটি একটি বিদ্যমান টেবিলের স্কিমা পরিবর্তন করতে ব্যবহৃত হয়৷

def change
  change_table :events do |t|
    t.remove :category
    t.string :event_type
    t.boolean :active, default: false
  end
end

এই স্থানান্তর category মুছে ফেলবে events থেকে কলাম টেবিল, একটি নতুন স্ট্রিং কলাম যোগ করুন events_type এবং একটি নতুন বুলিয়ান কলাম active false এর ডিফল্ট মান সহ .

রেলগুলি আরও অনেক সাহায্যকারী পদ্ধতি সরবরাহ করে যা একটি মাইগ্রেশনের মধ্যে ব্যবহার করা যেতে পারে যেমন:

• change_column
• add_index
• remove_index
• rename_table

এবং আরো অনেক. পরিবর্তনের সাথে ব্যবহার করা যেতে পারে এমন সমস্ত পদ্ধতি এখানে পাওয়া যাবে

টাইমস্ট্যাম্প

আমরা t.timestamps দেখেছি রেল দ্বারা মাইগ্রেশনে যোগ করা হয়েছিল এবং এটি created_at কলাম যোগ করেছে এবং updated_at events-এ টেবিল এই বিশেষ কলামগুলি রেল দ্বারা ব্যবহার করা হয় যখন একটি রেকর্ড তৈরি করা হয় এবং আপডেট করা হয় তা ট্র্যাক রাখতে৷ রেলগুলি এই কলামগুলিতে মান যোগ করে যখন একটি রেকর্ড তৈরি করা হয় এবং রেকর্ড আপডেট করা হলে সেগুলি আপডেট করা নিশ্চিত করে৷ এই কলামগুলি ডাটাবেস রেকর্ডের জীবনকাল ট্র্যাক করতে আমাদের সাহায্য করে৷

updated_at যখন আমরা updated_all চালাই তখন কলাম আপডেট হয় না রেল থেকে পদ্ধতি।

ব্যর্থতা হ্যান্ডলিং

মাইগ্রেশন বুলেটপ্রুফ নয়। তারা ব্যর্থ হতে পারে। কারণটি ভুল সিনট্যাক্স বা একটি অবৈধ ডেটাবেস ক্যোয়ারী হতে পারে। কারণ যাই হোক না কেন, আমাদের ব্যর্থতাকে পরিচালনা করতে হবে এবং এটি থেকে পুনরুদ্ধার করতে হবে যাতে ডাটাবেস একটি অসামঞ্জস্যপূর্ণ অবস্থায় না যায়। রেল একটি লেনদেনের মধ্যে প্রতিটি অভিবাসন চালিয়ে এই সমস্যার সমাধান করে। যদি মাইগ্রেশন ব্যর্থ হয়, তাহলে লেনদেনটি ফিরিয়ে আনা হয়৷ এটি নিশ্চিত করে যে ডাটাবেসটি একটি অসামঞ্জস্যপূর্ণ অবস্থায় না যায়৷

এটি শুধুমাত্র ডাটাবেসের জন্য করা হয় যা ডাটাবেস স্কিমা আপডেট করার জন্য লেনদেন সমর্থন করে। এগুলি ডেটা ডেফিনিশন ল্যাঙ্গুয়েজ (DDL) লেনদেন হিসাবে পরিচিত। MySQL এবং PostgreSQL উভয়ই DDL লেনদেন সমর্থন করে।

কখনও কখনও, আমরা একটি লেনদেনের মধ্যে নির্দিষ্ট স্থানান্তর চালাতে চাই না। PostgreSQL-এ সমবর্তিত সূচক যোগ করার সময় একটি সহজ উদাহরণ। এই ধরনের মাইগ্রেশনগুলি একটি DDL লেনদেনের মধ্যে সম্পাদন করা যাবে না যেমন PostgreSQL চেষ্টা করে টেবিলে লকগুলি অর্জন না করেই সূচক যোগ করার জন্য যাতে আমরা ডাটাবেস নামিয়ে না নিয়ে একটি লাইভ প্রোডাকশন ডাটাবেসে সূচক যুক্ত করতে পারি। রেলগুলি disable_ddl_transactions! আকারে মাইগ্রেশনের মধ্যে লেনদেনগুলি অপ্ট-আউট করার একটি উপায় প্রদান করে .

def change
  disable_ddl_transactions!
 
  add_index :events, :user_id, algorithm: :concurrently

এটি একটি লেনদেনের মধ্যে মাইগ্রেশন চালাবে না। যদি এই ধরনের অভিবাসন ব্যর্থ হয়, আমাদের নিজেদেরই তা পুনরুদ্ধার করতে হবে। এই ক্ষেত্রে, আমরা হয় REINDEX করতে পারি অথবা সূচী সরান এবং আবার যোগ করার চেষ্টা করুন।

প্রত্যাবর্তনযোগ্য মাইগ্রেশন

রেলগুলি আমাদের নিম্নলিখিত কমান্ডের সাহায্যে ডাটাবেসে পরিবর্তনগুলি রোলব্যাক করতে দেয়৷

rails db:rollback

এই কমান্ডটি ডাটাবেসে চালানো শেষ মাইগ্রেশনকে ফিরিয়ে দেয়। যদি মাইগ্রেশন একটি কলাম event_type যোগ করে তারপর রোলব্যাক সেই কলামটি মুছে ফেলবে। যদি মাইগ্রেশন একটি সূচী যোগ করে, তাহলে রোলব্যাক সেই সূচকটি সরিয়ে দেবে৷

পূর্ববর্তী মাইগ্রেশন রোলব্যাক এবং এটি চালানোর জন্য একটি কমান্ড রয়েছে। এটি হল rails db:redo .

বেশিরভাগ মাইগ্রেশন কিভাবে রিভার্স করতে হয় তা জানার জন্য রেল যথেষ্ট স্মার্ট। কিন্তু আমরা রেলসনকে ইঙ্গিতও দিতে পারি কিভাবে up দিয়ে মাইগ্রেশন ফিরিয়ে আনতে হয়। এবং down change ব্যবহার করার পরিবর্তে পদ্ধতি পদ্ধতি। up যখন মাইগ্রেশন চালানো হয় তখন পদ্ধতি ব্যবহার করা হবে যেখানে down যখন মাইগ্রেশন রোল ব্যাক করা হয় তখন পদ্ধতি ব্যবহার করা হবে।

def up
  change_table :events do |t|
    t.change :price, :string
  end
end
 
def down
  change_table :events do |t|
    t.change :price, :integer
  end
end

এই উদাহরণে, আমরা price পরিবর্তন করছি events কলাম integer থেকে string-এ . আমরা down-এ এটিকে কীভাবে ফিরিয়ে আনা উচিত তা উল্লেখ করি পদ্ধতি।

এই একই মাইগ্রেশন change ব্যবহার করেও লেখা যেতে পারে পদ্ধতি।

def change
  reversible do |direction|
    change_table :events do |t|
      direction.up { t.change :price, :string }
      direction.down { t.change :price, :integer }
    end
  end
end

রেলগুলি revert ব্যবহার করে সম্পূর্ণরূপে পূর্ববর্তী স্থানান্তরকে প্রত্যাবর্তনের একটি উপায়ও প্রদান করে পদ্ধতি।

def change
  revert CreateEvents
 
  create_table :events do
   ...
  end
end

revert পদ্ধতি আংশিকভাবে একটি মাইগ্রেশন প্রত্যাবর্তনের জন্য একটি ব্লক গ্রহণ করে৷

def change
  revert do
    reversible do |direction|
      change_table :events do |t|
        direction.up { t.remove :event_type }
        direction.down { t.string :event_type }
      end
    end
  end
end

এটি কাঁচা চালানো হচ্ছে

কখনও কখনও, আমরা একটি মাইগ্রেশনের ভিতরে জটিল SQL চালাতে চাই। এই ধরনের ক্ষেত্রে, আমরা সাধারণ মাইগ্রেশন ডিএসএলকে ভুলে যেতে পারি এবং পরিবর্তে নিম্নরূপ কাঁচা SQL চালাতে পারি।

def change
  execute <<-SQL
    ....
  SQL
end

একাধিক ডেটাবেস এবং মাইগ্রেশন

Rails 6 একটি একক Rails অ্যাপ্লিকেশনের মধ্যে একাধিক ডাটাবেস ব্যবহার করার জন্য সমর্থন যোগ করেছে৷ আমরা যদি একাধিক ডেটাবেস ব্যবহার করতে চাই, আমরা সেগুলি database.yml-এ কনফিগার করি। ফাইল।

development:
  primary:
    <<: *default
    database: db/development.sqlite3
  analytics:
    adapter: sqlite3
    database: db/analytics_dev.sqlite3

এই কনফিগারেশন রেলকে বলে যে আমরা দুটি ডেটাবেস ব্যবহার করতে চাই—primary এবং analytics .যেমন আমরা আগে দেখেছি, মাইগ্রেশনগুলি db/migrate-এ সংরক্ষণ করা হয় ডিফল্টরূপে ডিরেক্টরি। কিন্তু এই ক্ষেত্রে, আমরা একটি একক ডিরেক্টরির মধ্যে উভয় ডাটাবেসের স্থানান্তর যোগ করতে পারি না। আমরা analytics-এর মাইগ্রেশন চালাতে চাই না primary-এ ডাটাবেস ডাটাবেস এবং তদ্বিপরীত। যদি আমরা একাধিক ডাটাবেস ব্যবহার করি, তাহলে দ্বিতীয় ডাটাবেসের জন্য মাইগ্রেশন সঞ্চয় করার জন্য একটি পথ প্রদান করতে হবে। এটি একটি migrations_paths প্রদান করে করা যেতে পারে database.yml-এ .

development:
  primary:
    <<: *default
    database: db/development.sqlite3
  analytics:
    adapter: sqlite3
    database: db/analytics_dev.sqlite3
    migrations_paths: db/analytics_migrate

তারপর আমরা analytics-এর জন্য মাইগ্রেশন তৈরি করতে পারি নিম্নরূপ ডাটাবেস।

rails generate migration AddExperiments rule:string active:boolean --db=analytics

এটি db/analytics_migrate-এর মধ্যে মাইগ্রেশন তৈরি করবে , এবং আমরা এটিকে নিম্নরূপ চালাতে পারি।

rails db:migrate --db=analytics

যদি আমরা শুধুমাত্র rails db:migrate চালাই , এটি সমস্ত ডাটাবেসের জন্য মাইগ্রেশন চালাবে।

analytics ডাটাবেসের নিজস্ব schema_migrations থাকবে কোন স্থানান্তর চালানো হয় এবং কোনটি নয় তা ট্র্যাক করার টেবিল।

স্থাপনের সময় মাইগ্রেশন চালানো

যেহেতু মাইগ্রেশনগুলি ডাটাবেসের অবস্থা পরিবর্তন করতে পারে, এবং আমাদের কোড সেই পরিবর্তনগুলির উপর নির্ভর করতে পারে, এটি অত্যন্ত গুরুত্বপূর্ণ যে নতুন কোড প্রয়োগ করার আগে মাইগ্রেশনগুলি প্রথমে চালানো হয়৷

হেরোকু ভিত্তিক স্থাপনায়, মাইগ্রেশনগুলি release-এ চালানো যেতে পারে Procfile এর ফেজ .

# Profile
web: bin/puma -C config/puma.rb
release: bundle exec rake db:migrate

এটি নিশ্চিত করে যে অ্যাপ ডাইনোগুলি পুনরায় চালু হওয়ার আগে মাইগ্রেশনগুলি চালানো হয়৷

Capistrano ভিত্তিক স্থাপনায়, সার্ভার পুনরায় চালু হওয়ার আগে মাইগ্রেশন চালানো উচিত।

ডকার ভিত্তিক স্থাপনায়, অ্যাপটি পুনরায় চালু হওয়ার আগে প্রথমে মাইগ্রেশন চালানোর জন্য আমরা একটি সাইডকার কন্টেইনার চালাতে পারি। এটি খুবই গুরুত্বপূর্ণ কারণ অন্যথায়, নতুন কন্টেইনারগুলি একটি অসামঞ্জস্যপূর্ণ অবস্থায় যেতে পারে যদি তারা সেই নতুন কোডের জন্য ডাটাবেস পরিবর্তনগুলি প্রয়োগ করার আগে নতুন কোড ব্যবহার করা শুরু করে।

উপসংহার

এই পোস্টে, আমরা রেলে ডাটাবেস মাইগ্রেশন লেখার বিভিন্ন দিক দেখেছি। আমরা আরও দেখেছি যে মাইগ্রেশন কী গঠন করে সেইসাথে কীভাবে ব্যর্থতাগুলি পরিচালনা করা যায় এবং প্রয়োজনে মাইগ্রেশনগুলিকে ফিরিয়ে আনা যায়। Rails 6 আমাদের একাধিক ডাটাবেস ব্যবহার করতে দেয় এবং প্রতিটির জন্য আলাদাভাবে যোগ করতে হয়। অবশেষে, আমরা সংক্ষেপে দেখেছি কিভাবে স্থাপনার সময় মাইগ্রেশন চালাতে হয় যাতে কোনো নতুন কোড ব্যবহার শুরু করার আগে ডাটাবেস পরিবর্তনগুলি সঠিকভাবে প্রয়োগ করা হয়।

পি.এস. আপনি যদি রুবি ম্যাজিক পোস্টগুলি প্রেস থেকে বের হওয়ার সাথে সাথে পড়তে চান তবে আমাদের রুবি ম্যাজিক নিউজলেটারে সাবস্ক্রাইব করুন এবং একটি পোস্ট মিস করবেন না!