রেক ডিবি: স্কিমা: লোড বনাম মাইগ্রেশন


171

এখানে খুব সাধারণ প্রশ্ন - কোনও অ্যাপ্লিকেশন আরও জটিল হয়ে যাওয়ার সাথে সাথে যদি মাইগ্রেশনগুলি ধীর এবং জটিল হয়ে উঠতে পারে এবং rake db:schema:loadতার পরিবর্তে আমাদের কল করার মতো আরও ক্লিনার থাকে তবে মাইগ্রেশন কেন একেবারেই বিদ্যমান?

যদি উপরের উত্তরটি হ'ল মাইগ্রেশনগুলি ভার্সন নিয়ন্ত্রণের জন্য ব্যবহৃত হয় (ডাটাবেসে পরিবর্তনের একটি ধাপের রেকর্ড), তবে কোনও অ্যাপ্লিকেশনটি আরও জটিল হয়ে ওঠে এবং rake db:schema:loadপরিবর্তে আরও ব্যবহৃত হয়, তারা কি তাদের প্রাথমিক কাজটি চালিয়ে যেতে চান?


সতর্ক করা:

এই প্রশ্নের উত্তর থেকে: একটি প্রোডাকশন সার্ভারের rake db:schema:load ডেটা মুছে ফেলবে তাই এটি ব্যবহার করার সময় সতর্ক থাকুন।


5
+1 আমি কখনই মাইগ্রেশনের উদ্দেশ্য বুঝতে পারি নি; কেন কেবল সংস্করণটি স্কিমা নিয়ন্ত্রণ করে না?
বিকল্প

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

উত্তর:


208

অভিবাসনগুলি ডাটাবেসে সামনের ও পিছনের পদক্ষেপের পরিবর্তন সরবরাহ করে। উত্পাদনের পরিবেশে, মোতায়েনের সময় ডেটাবেজে বর্ধিত পরিবর্তনগুলি করতে হবে: মাইগ্রেশনগুলি রোলব্যাক ব্যর্থতার সাথে এই কার্যকারিতা সরবরাহ করে। আপনি যদি rake db:schema:loadকোনও প্রোডাকশন সার্ভারে চালনা করেন তবে আপনি আপনার সমস্ত ডেটা মুছে ফেলবেন। এটি aোকা একটি বিপজ্জনক অভ্যাস।

এটি বলা হচ্ছে, আমি বিশ্বাস করি যে মাঝেমধ্যে "ধসে পড়া" স্থানান্তরিত করা একটি শালীন অনুশীলন। এটি পুরানো মাইগ্রেশন মুছে ফেলা, তাদের পরিবর্তে একটি একক স্থানান্তর (আপনার schema.rbফাইলের সাথে খুব সমান ) অন্তর্ভুক্ত করে এবং schema_migrationsএই পরিবর্তনটি প্রতিফলিত করতে টেবিল আপডেট করে । এটি করার সময় খুব সাবধান! আপনি যত্নবান না হলে আপনি সহজেই আপনার উত্পাদন ডেটা মুছতে পারেন।

পার্শ্ব নোট হিসাবে, আমি দৃ strongly়ভাবে বিশ্বাস করি যে আপনার স্থানান্তর ফাইলগুলিতে কখনই ডেটা তৈরি করা উচিত নয়। seed.rbফাইল বা কাস্টম মই দিয়া আহরণ করা বা প্রয়োগের কর্ম এই জন্য ব্যবহার করা যেতে পারে। এটিকে মাইগ্রেশন ফাইলগুলিতে রাখলে আপনার ডেটাবেস স্কিমার স্পেসিফিকেশনটি আপনার ডেটা স্পেসিফিকেশনের সাথে মিশে যায় এবং মাইগ্রেশন ফাইলগুলি চালানোর সময় দ্বন্দ্বের জন্ম দিতে পারে।


80
রেক ডিবি: স্কিমা: লোড সমস্ত উত্পাদন ডেটা মুছে ফেলার জন্য আপনাকে ধন্যবাদ!
ম্যাগনে

2
"ধসে পড়া" মাইগ্রেশনগুলির পরিবর্তে স্কিমার নকল করে এমন একটি নতুনের পরিবর্তে, আমি একটি রত্ন লিখেছিলাম যা কেবল তাদের সাফ করে দেয় এবং ব্যবহারকারীরা db:schema:loadযদি db:migrateনতুন কোনও ইনস্টলের বিরুদ্ধে চালানোর চেষ্টা করে তবে তারা ব্যবহার করতে অনুরোধ করবে । @ ক্লিয়ার_ইমিগ্রেশন
ইয়ারিন

সম্ভবত একটি সুস্পষ্ট উত্তর কিন্তু উত্পাদনের প্রথম ধাক্কা দেওয়ার আগে, আপনি কেবলমাত্র সমস্ত মাইগ্রেশন মুছে ফেলার এবং প্রথম স্থানান্তর হিসাবে db.schema ব্যবহার করার পরামর্শ দিবেন?
dtc

30

এই পোস্টটি জুড়ে কেবল হোঁচট খেয়েছে, এটি বহু আগে ছিল এবং আমি যে উত্তরটি প্রত্যাশা করছিলাম তা দেখেনি।

rake db:schema:loadআপনি যখন প্রথমবারের মতো কোনও প্রোডাক্ট তৈরি করলেন তখন দুর্দান্ত। এর পরে আপনার সাধারণত মাইগ্রেশন চালানো উচিত।

এটি যখনই আপনি চান আপনার স্থানান্তরগুলি পরিষ্কার করতে সহায়তা করে, যেহেতু আপনি যখন নিজের স্থানান্তরগুলি পরিষ্কার করেছেন তখনও স্কিমাতে অন্যান্য মেশিনগুলিকে উত্পাদনে রাখার সমস্ত তথ্য রয়েছে।


সুতরাং আপনি আপনার স্থানান্তরগুলি "শুদ্ধ" করতে পারেন কারণ আপনাকে সেগুলি কখনই ব্যবহার করতে হবে না? উদ্ভট বক্তব্যের মতো শোনাচ্ছে।
আবে পেট্রিলো

db:schema:loadবিকাশের চক্র জুড়ে একবারে কয়েক সেকেন্ড শেভ করা ছাড়া আর কী কী লাভ তা আমার কাছে অস্পষ্ট । আপনি কি এমন অ্যাপ্লিকেশন নিয়ে কাজ করেছেন যেটি তৈরি হতে 30 সেকেন্ডের বেশি সময় নিয়েছে? আমি বর্তমানে এমন একটি অ্যাপের সাথে কাজ করছি যার মাইগ্রেশন ফাইলগুলিতে বাগ রয়েছে এবং এটি কোনও বাগ ফিক্স না থাকলে বা চালনা ছাড়াই কখনই স্থানান্তরিত হবে না db:schema:loadযা আমাকে স্কিমা ভাবায়: লোডটি যখন অ্যাপটির বিকাশের বিষয়ে কিছু ভুল হয়ে যায় wrong
নিনজাক্সর

মাইগ্রেশন রক্ষার জন্য আমি আরও একটি যুক্তি করব যে রেল কোর টিম ব্যবহারকারীদের নির্দেশ দেয় instead of editing schema.rb, please use the migrations feature। সুতরাং আপনি যদি db:schema:loadস্বয়ংক্রিয়ভাবে উত্পন্ন ফাইলটিতে চালিত হন যা আপনাকে আবার স্বয়ংক্রিয়ভাবে উত্পন্ন করার জন্য মাইগ্রেশন নেই, আপনি কার্যকরভাবে স্কিমার "সম্পাদনা" করার এবং মাইগ্রেশনগুলি নিষ্ক্রিয় করার পথে চলে যাচ্ছেন। আমি আশা করি এটি সম্পর্কে রেল গাইডের কাছ থেকে উদ্ধৃতি পেয়েছি, তবে তারা স্কিমা: লোড নিয়ে আলোচনা করে না, যা স্কিমা: লোড বৈশিষ্ট্যটির কাছে কীভাবে যেতে হবে তা সিদ্ধান্ত নেওয়ার ক্ষেত্রে আমার হতাশাকে সাহসের সাথে যুক্ত করে। = /
নিনজাক্সর

আমি এই পৃষ্ঠায় স্পষ্টভাবে এসেছি কারণ আমি তার সাথে একমত। আমার অভিজ্ঞতা হ'ল একবার সাইটটি উত্পাদনের পরে এটি পরিবর্তন করতে মাইগ্রেশন ব্যবহার করা অনেক বেশি নিরাপদ। তবুও, ডিবি / স্কিমা.আরবি শুরুর মন্তব্যগুলি একেবারে বিপরীতভাবে জানিয়েছে! (প্রতিটি প্রকল্পের শুরুতে আমার সমস্যা আছে কারণ আমি .gitignore এ ডিবি / স্কিমা.আরবি স্থাপন করা ভুলে গেছি ...)
ব্যবহারকারী 1251840

@ আবেপেট্রিলো বাহ আমি এই মন্তব্যগুলি পুরোপুরি মিস করেছি। অবশ্যই তা নয়, আমি যা বোঝাতে চাইছিলাম তা হল আপনি যদি ইচ্ছা করেন তবে সমস্ত উত্পাদন মেশিনে চালানো পুরানো মাইগ্রেশনগুলি পরিষ্কার করতে পারেন । বছরের পর বছরগুলিতে আমি সর্বদা তাদের আশেপাশে রেখেছি, তবে আমার "যখনই আপনার পছন্দগুলি আপনার স্থানান্তর পরিষ্কার করতে সহায়তা করে" বিবৃতিটির অর্থ এই ছিল না যে "আমাকে কখনই মাইগ্রেশন ব্যবহার করতে হবে না"। সুতরাং, আপনি যখন একটি নতুন মেশিন স্থাপন করবেন তখন তার rake db:schema:loadবিপরীতে চালান rake db:migrate। তারপরে সেখান থেকে আপনি পারবেন rake db:migrate
এরেসলিবারে

9

অভিবাসনগুলি আপনাকে ডিবিতেও ডেটা যুক্ত করতে দেয়। তবে ডিবি: স্কিমা: লোড শুধুমাত্র স্কিমা লোড করে।


6

কারণ মাইগ্রেশনগুলি আবার ঘুরিয়ে দেওয়া যায় এবং অতিরিক্ত কার্যকারিতা সরবরাহ করা যেতে পারে। উদাহরণস্বরূপ, যদি আপনাকে স্কিমা পরিবর্তনের অংশ হিসাবে কিছু তথ্য সংশোধন করতে হয় তবে আপনাকে তা স্থানান্তর হিসাবে করতে হবে।


4

অন্যান্য ওআরএম-র ব্যবহারকারী হিসাবে আমার কাছে সর্বদা অদ্ভুত লাগছিল যে রেলগুলির কোনও 'সিঙ্ক এবং আপডেট' বৈশিষ্ট্য নেই। উদাহরণস্বরূপ, স্কিমা ফাইল ব্যবহার করে (যা সম্পূর্ণরূপে আপ টু ডেট স্কিমাকে উপস্থাপন করে) বিদ্যমান ডিবি কাঠামো পেরিয়ে সারণি, কলাম, সূচীগুলি প্রয়োজনীয় / যোগ / সরান।

আমার কাছে এটি আরও শক্তিশালী হবে, এমনকি যদি সম্ভবত সামান্য ধীর হয়।


1
একটি জটিল স্কিমা থেকে অন্যটিতে ডেটাবেস সহ ডেটাবেস স্থানান্তরিত করার কাজটি কিছু সময় ক্ষুদ্র হয় না। এটি স্বয়ংক্রিয়ভাবে সমাধান না হতে পারে এবং একক পদক্ষেপের সাথে ডেটা ধারাবাহিকভাবে স্থানান্তরিত নাও হতে পারে। রেলের স্থানান্তর মাস্টার এবং স্কিমা নির্ভর। স্কিমা স্বয়ংক্রিয়ভাবে প্রতিটি মাইগ্রেশন দিয়ে পুনরায় তৈরি করা হয়েছে তবে বিপরীতে নয়।
ওকালাস

রেলের নিজস্ব গাইডগুলি স্পষ্টভাবে জানিয়েছে যে schemaহস্তান্তর নয়, মাস্টার।
ড্রেনমি

0

আমি ইতিমধ্যে একটি মন্তব্য হিসাবে পোস্ট করেছি, তবে ডিবি / স্কিমা.আরবি ফাইলের মন্তব্যগুলি এখানে রাখাই ভাল বলে মনে করি:

# Note that this schema.rb definition is the authoritative source for your
# database schema. If you need to create the application database on another
# system, you should be using db:schema:load, not running all the migrations
# from scratch. The latter is a flawed and unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for issues).
#
# It's strongly recommended that you check this file into your version control system.

প্রকৃতপক্ষে, আমার অভিজ্ঞতা হ'ল মাইগ্রেশন ফাইলগুলি গিটে রাখা ভাল, স্কিমা.আরবি ফাইলের চেয়ে নয় ...


0

rake db:migrateডাটাবেসে টেবিল সেটআপ করুন। আপনি যখন মাইগ্রেশন কমান্ডটি চালাবেন, এটি কোনও রুবি ফাইলের জন্য ডিবি / মাইগ্রেট / সন্ধান করবে এবং এটিকে সবচেয়ে পুরানো দিয়ে শুরু করবে। প্রতিটি স্থানান্তর ফাইলের নামের শুরুতে একটি টাইমস্ট্যাম্প থাকে।

rake db:migrateযেগুলি মাইগ্রেশনগুলি চালায় না যা এখনও চালায়নি তার বিপরীতে , rake db:schema:loadইতিমধ্যে db/schema.rbডেটাবেজে তৈরি হওয়া স্কিমাটি লোড করে।

আপনি এখানে রেক ডাটাবেস কমান্ড সম্পর্কে আরও জানতে পারেন ।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.