جادوی مهاجرت ✨، مدیریت محدودیت‌های غیر پوچ در تولید با Ruby on Rails

همه ما با خوشحالی در حال اضافه کردن جداول و ستون های جدید به برنامه های خود در محیط توسعه بوده ایم. و وقتی همه چیز بد پیش می‌رود، جدول را رها می‌کنیم و تازه شروع می‌کنیم، بدون آسیب، بدون خطا. اما وقتی در مرحله تولید با مسائلی مواجه می شویم چه اتفاقی می افتد؟ این زمانی است که چالش شروع می شود. در این پست، ما با یک سناریوی مهاجرت پیچیده که شامل محدودیت‌های غیر تهی است می‌پردازیم و نکات عملی را برای جلوگیری از از دست دادن داده‌ها در تولید به اشتراک می‌گذاریم. پس دست و پنجه نرم کنید و بیایید داخل شیرجه بزنیم! 🚀

😌 سعادت مرحله توسعه

در حالی که من روی برنامه validateok.click کار می کنم، باید یک ستون جدید اضافه کنم category به یک جدول موجود ideas. در اینجا یک نمونه مهاجرت آورده شده است:

class AddCategoryToIdeas < ActiveRecord::Migration[7.1]   
    def change     
        add_reference :ideas, 
                      :category, 
                      default: 'Tools', 
                      null: false, 
                      foreign_key: true, 
                      type: :uuid   
    end 
end

در محیط توسعه، اجرای این مهاجرت آسان است و همه چیز همانطور که انتظار می رود کار می کند. اما در مورد تولید چطور؟ 😰

😬 موانع مرحله تولید

در تولید، حذف یک پایگاه داده یک گزینه نیست، مگر اینکه مایل باشیم همه چیز را از دست بدهیم – و هیچ کس این را نمی خواهد! 😱 استفاده از همان مراحل مهاجرت که در توسعه بالا انجام دادیم 👆🏼 می تواند منجر به خطاهایی شود، مانند این:

ActiveRecord::NotNullViolation: PG::NotNullViolation: ERROR: column "category_id" of relation "ideas" contains null values

خطا به این دلیل رخ می دهد که رکوردهای موجود در ideas جدول ندارد category_id ارزش، نه تنها این، و ما تنظیم کرده ایم null: false محدودیت برای رفع این مشکل چه کنیم؟ 🤔

🪄 راه حل

جای نگرانی نیست! ما راه حل عالی برای شما داریم💡. بیایید از طریق مراحل مورد نیاز برای مدیریت برازنده این مهاجرت در تولید قدم برداریم.

مرحله 1: مقدار پیش فرض را حذف کرده و مهاجرت را به دو قسمت تقسیم کنید

ابتدا مقدار پیش‌فرض «ابزار» را همانطور که باید a باشد، از انتقال حذف کنید UUID، یک رشته نیست. این اشتباه من است زیرا توجه نکردم که از UUID استفاده می کنم. آیا من تنها هستم🤦‍♂️ سپس، مهاجرت را به دو مرحله تقسیم کنید:

1. اضافه کردن category_id ستون بدون null: false ایده های موجود را با یک دسته بندی پیش فرض محدود و پر کنید.
2. در نهایت، را اضافه کنید null: false محدودیت

در اینجا فایل مهاجرت به روز شده است:

class AddCategoryToIdeas < ActiveRecord::Migration[7.1]
  def up
    add_reference :ideas, :category, foreign_key: true, type: :uuid #1

    default_category = Category.find_or_create_by!(name: 'Tools')
    Idea.update_all(category_id: default_category.id)

    change_column_null :ideas, :category_id, false #2
  end

  def down
    remove_reference :ideas, :category
  end
end

مرحله 2: هدف هر مرحله را درک کنید

1. اضافه کردن category_id ستون بدون null: false محدودیت این به ما امکان می دهد تا رکوردهای موجود را بدون نقض محدودیت غیر تهی به روز کنیم.
2. یک دسته بندی پیش فرض به نام «ابزار» را پیدا یا ایجاد کنید و شناسه آن را به عنوان پیش فرض تنظیم کنید category_id برای تمام ایده های موجود این تضمین می کند که همه ایده های موجود معتبر هستند category_id ارزش.
3. اضافه کردن null: false محدودیت به category_id ستون اکنون که تمام ایده های موجود با یک پیش فرض به روز شده اند category_id، می توانیم با خیال راحت محدودیت غیر تهی را اعمال کنیم.
4. و اکنون می توانید با اطمینان بدوید rails db:migrate

🗞 بسته بندی

و شما آن را دارید، مردمی! به لطف این مراحل، ما بدون از دست دادن هیچ داده ای، یک مهاجرت بالقوه مشکل را در محیط تولید به خوبی مدیریت کرده ایم. با تقسیم مهاجرت به دو بخش، به‌روزرسانی رکوردهای موجود، و سپس اعمال محدودیت غیر تهی، برنامه خود را قوی‌تر و قابل اعتمادتر کرده‌ایم.

به یاد داشته باشید، به عنوان توسعه دهندگان Rails، ضروری است که در مورد تأثیر مهاجرت db خود در محیط های توسعه و تولید فکر کنید. با کمی بینش و چند ایموجی با جانمایی مناسب، می‌توانیم بر این چالش‌ها غلبه کنیم و به ساخت اپلیکیشن‌های فوق‌العاده ادامه دهیم.

مثل همیشه کدنویسی مبارک و تا دفعه بعد! 🚀