Migration — ใบสั่งช่างต่อเติมตู้ และแปลนตู้ฉบับล่าสุด

ปัญหา: ร้าน 5 สาขา ช่างต่อเติมตู้แบบปากเปล่า

schema คือ "หน้าตาของฐานข้อมูล" — มีตารางอะไร แต่ละตารางมีคอลัมน์ชื่ออะไร เก็บข้อมูลชนิดไหน · โค้ดของเราพึ่ง schema ตลอด เช่น ถ้าโค้ดอ่าน post.subtitle แต่ตารางไม่มีคอลัมน์ subtitle แอปพังทันที

ปัญหาคือ schema อยู่ในฐานข้อมูล ไม่ได้อยู่ในโค้ด · สไลด์หน้า 12 ยกสถานการณ์ให้: ทีม 5 คน · เครื่อง 5 เครื่อง · ฐานข้อมูลของเว็บจริง 1 ตัว

• พี่ A เพิ่มคอลัมน์ในเครื่องตัวเองด้วยโปรแกรมจัดการฐานข้อมูล (คลิก ๆ เอา) แล้ว push (ส่งโค้ดขึ้นที่เก็บกลางของทีม) โค้ดที่ใช้คอลัมน์นั้น
• พี่ B ดึงโค้ดมา → ในเครื่องพี่ B ไม่มีคอลัมน์นั้น → แอปพัง · ไม่มีใครบอก
• ขึ้นเว็บจริงก็ลืมเพิ่มคอลัมน์อีก → เว็บล่ม
• สามเดือนผ่านไป มีคนถาม "คอลัมน์นี้ใครเพิ่ม เพิ่มทำไม" — ไม่มีใครตอบได้

(เครื่องของเราแต่ละคนเรียกว่า development · เว็บจริงที่ลูกค้าใช้อยู่เรียกว่า production · แต่ละที่มีฐานข้อมูลของตัวเองแยกกัน)

migration แก้ทุกข้อด้วยวิธีเดียว: ทุกการเปลี่ยน schema ต้องเขียนเป็นไฟล์หนึ่งไฟล์เก็บใน git · ใครดึงโค้ดไปก็ได้ไฟล์ไปด้วย สั่ง bin/rails db:migrate ทีเดียว ฐานข้อมูลในเครื่องเขาก็หน้าตาเหมือนของเรา · และ git log (ดูประวัติ commit) ตอบได้ว่าใครเพิ่ม เพิ่มเมื่อไหร่ (คำว่า "ทำไม" ตอบได้ถ้าเขียน commit message ดี)

เทียบกับ goose ที่เคยใช้ใน Go

ในบท 31 คุณเขียน migration ของ Go ด้วย goose มาแล้ว · แนวคิดเหมือนกันทุกอย่าง ต่างแค่ภาษาที่เขียน: goose ให้เขียน SQL ตรง ๆ สองท่อน (ทำ · ย้อน) ส่วน Rails ให้เขียน Ruby ท่อนเดียว แล้วมันคิดวิธีย้อนให้เอง

-- +goose Up
ALTER TABLE posts ADD COLUMN subtitle VARCHAR;

-- +goose Down
ALTER TABLE posts DROP COLUMN subtitle;

class AddSubtitleToPosts < ActiveRecord::Migration[8.1]
  def change
    add_column :posts, :subtitle, :string
  end
end

อ่านฝั่ง goose ทีละบรรทัด (SQL แปลเป็นภาษาคน):

• -- +goose Up / -- +goose Down — ป้ายบอก goose ว่าท่อนไหนขาไป ท่อนไหนขากลับ (-- คือคอมเมนต์ของ SQL)
• ALTER TABLE posts ADD COLUMN subtitle VARCHAR; — "ขอดัดแปลงลิ้นชัก posts: เพิ่มช่องชื่อ subtitle เก็บข้อความ" · ALTER TABLE = ดัดแปลงตาราง · ADD COLUMN = เพิ่มคอลัมน์ · VARCHAR = ข้อความ (ตรงกับ :string ของ Rails)
• ALTER TABLE posts DROP COLUMN subtitle; — "ขอดัดแปลงลิ้นชัก posts: รื้อช่อง subtitle ทิ้ง" · DROP = รื้อทิ้ง

ฝั่ง Rails อ่านทีละคำในหัวข้อถัดไป · ตอนนี้ดูแค่ว่ามันสั้นกว่า และไม่มีท่อนขากลับ (ไฟล์ goose ผมเขียนให้ดูเทียบ ไม่ได้รันในบทนี้ · ไฟล์ Rails คือไฟล์ที่ Rails สร้างให้จริง — เดี๋ยวได้สร้างเอง)

ส่วน AutoMigrate ของ GORM (บท 27) ไม่ใช่ migration แบบนี้ — มันดู struct แล้ว "เติมของที่ขาด" อย่างเดียว ไม่มีไฟล์ ไม่มีประวัติ (บท 31 เห็นแล้วว่าเปลี่ยนชื่อ field แล้วได้คอลัมน์ว่างเพิ่มมาเฉย ๆ)

เปิดแฟ้มใบสั่งช่าง: db/migrate/ ของจริง

ในแอปที่ทำต่อจากบท 107 มีใบสั่งช่างอยู่ 5 ใบ · ลองสั่ง ls ดู (ผลจริง):

$ ls db/migrate
20261104113601_create_posts.rb
20261104113603_add_published_and_views_to_posts.rb
20261104113604_create_users.rb
20261104113606_add_user_to_posts.rb
20261104113607_create_comments.rb

• ตัวเลข 14 หลักข้างหน้าคือ วันเวลาที่สร้างไฟล์ อ่านว่า ปี 2026 · เดือน 11 · วันที่ 04 · 11:36:01 (เวลาสากล UTC — เวลาไทยต้องบวก 7 ชั่วโมง เลขเลยไม่ตรงนาฬิกาในเครื่อง ไม่ต้องตกใจ)
• เพราะเรียงตามเวลา ls จึงเรียงตามลำดับที่สร้างให้เอง และ Rails ก็ทำตามลำดับนี้ — ตาราง posts ต้องเกิดก่อน ถึงจะเพิ่มคอลัมน์ให้มันได้
• ตัวเลขนี้ยังเป็น เลขประจำตัวของใบนั้นด้วย (Rails เรียกว่า version) — จำไว้ อีกสองหัวข้อจะเห็นมันในฐานข้อมูล
• ส่วนหลังตัวเลข เช่น add_published_and_views_to_posts คือชื่อใบ อ่านเป็นภาษาอังกฤษได้: "เพิ่ม published กับ views ให้ posts"

เปิดใบที่สองดู — ใบที่เพิ่มสองช่องให้ตาราง posts:

# db/migrate/20261104113603_add_published_and_views_to_posts.rb
class AddPublishedAndViewsToPosts < ActiveRecord::Migration[8.1]
  def change
    add_column :posts, :published, :boolean, default: false, null: false
    add_column :posts, :views, :integer, default: 0, null: false
  end
end

• class AddPublishedAndViewsToPosts — ชื่อ class ตรงกับชื่อไฟล์ (กฎตั้งชื่อ บท 99) · ห้ามมีสองใบชื่อซ้ำกัน
• < ActiveRecord::Migration[8.1] — สืบทอดความสามารถ "แก้ตู้" มาจาก Rails · [8.1] = เขียนตามกติกาของ Rails รุ่น 8.1
• def change — สิ่งที่ใบนี้สั่งให้ทำ
• add_column :posts, :published, :boolean — เพิ่มคอลัมน์ในตาราง posts ชื่อ published เก็บค่า จริง/เท็จ
• default: false — แฟ้มที่ไม่ได้บอกค่ามา ให้เป็น false (ยังไม่เผยแพร่) · รวมถึงแฟ้มเก่าที่มีอยู่แล้วในลิ้นชักด้วย
• null: false — ห้ามว่าง (ห้ามเป็น nil) · เป็นกฎที่ตัวตู้บังคับเอง เรื่องเต็มอยู่บท 111
• บรรทัดที่สองเหมือนกัน แต่เป็นตัวเลข (:integer) ชื่อ views เริ่มที่ 0

schema.rb — แปลนตู้ฉบับล่าสุด

ถ้าอยากรู้ว่า "ตอนนี้ตาราง posts มีช่องอะไรบ้าง" ต้องไล่อ่านใบสั่งทั้ง 5 ใบแล้วรวมในหัวเอง — เหนื่อย · Rails เลยเขียนไฟล์ db/schema.rb ให้ทุกครั้งที่ migrate เสร็จ: สรุปหน้าตาฐานข้อมูล ณ ตอนนี้ ไว้ในไฟล์เดียว

ไฟล์จริงของแอปเรา (ตัดคอมเมนต์ภาษาอังกฤษ 11 บรรทัดแรกออก — ใจความคือ "ไฟล์นี้สร้างอัตโนมัติ อย่าแก้เอง ให้ใช้ migration และควร commit เข้า git"):

# db/schema.rb (ตัดคอมเมนต์ด้านบนออก)
ActiveRecord::Schema[8.1].define(version: 2026_11_04_113607) do
  # These are extensions that must be enabled in order to support this database
  enable_extension "pg_catalog.plpgsql"

  create_table "comments", force: :cascade do |t|
    t.text "body"
    t.bigint "post_id", null: false
    t.bigint "user_id", null: false
    t.datetime "created_at", null: false
    t.datetime "updated_at", null: false
    t.index ["post_id"], name: "index_comments_on_post_id"
    t.index ["user_id"], name: "index_comments_on_user_id"
  end

  create_table "posts", force: :cascade do |t|
    t.string "title"
    t.text "body"
    t.datetime "created_at", null: false
    t.datetime "updated_at", null: false
    t.boolean "published", default: false, null: false
    t.integer "views", default: 0, null: false
    t.bigint "user_id", null: false
    t.index ["user_id"], name: "index_posts_on_user_id"
  end

  create_table "users", force: :cascade do |t|
    t.string "name"
    t.string "email"
    t.datetime "created_at", null: false
    t.datetime "updated_at", null: false
  end

  add_foreign_key "comments", "posts"
  add_foreign_key "comments", "users"
  add_foreign_key "posts", "users"
end

อ่านทีละส่วน:

• version: 2026_11_04_113607 — เลขของใบสั่งช่างใบล่าสุดที่ทำแล้ว (ตรงกับ …113607_create_comments.rb) · ขีด _ แค่ช่วยให้อ่านง่าย
• enable_extension "pg_catalog.plpgsql" (และคอมเมนต์ภาษาอังกฤษข้างบนมัน ที่แปลว่า "ส่วนเสริมที่ต้องเปิดไว้ให้ฐานข้อมูลนี้ทำงานได้") — ส่วนเสริมมาตรฐานของ PostgreSQL ที่ Rails จดไว้ให้ · ไม่ต้องสนใจ
• create_table "posts", force: :cascade do |t| — สร้างตาราง posts · force: :cascade = "ถ้ามีตารางชื่อนี้อยู่แล้วให้รื้อทิ้งสร้างใหม่" (ใช้ตอนสร้างฐานข้อมูลใหม่จากแปลน)
• |t| — block ที่รู้จักจาก Day 1 · t คือ "ลิ้นชักที่กำลังสร้าง" · ทุกบรรทัด t.อะไร "ชื่อ" ข้างใน = เพิ่มช่องหนึ่งช่องให้ลิ้นชักนั้น
• t.string "title" · t.text "body" — คอลัมน์ข้อความสั้น กับข้อความยาว · บรรทัดพวกนี้มาจากใบแรก CreatePosts
• published · views — มาจากใบที่สอง · user_id — มาจากใบที่สี่ AddUserToPosts · แปลนรวมทุกใบไว้ในตารางเดียว ไม่สนว่ามาจากใบไหน
• t.bigint = ตัวเลขจำนวนเต็มขนาดใหญ่ (ใช้เก็บเลข id ของแถวอื่น) · t.datetime = วันและเวลา · t.boolean = จริง/เท็จ · t.integer = จำนวนเต็ม
• created_at · updated_at — เวลาสร้าง/แก้ล่าสุด Rails ใส่ให้เองทุกตาราง (มาจากบรรทัด t.timestamps ในใบ create)
• ไม่เห็นคอลัมน์ id — Rails สร้างให้ทุกตารางโดยอัตโนมัติ เลยไม่ต้องเขียน
• t.index [...] — สารบัญที่ช่วยให้หาแฟ้มตามช่องนั้นได้เร็ว (index — เรื่องเต็มบท 109)
• add_foreign_key "posts", "users" — กฎของตู้ว่า user_id ในแฟ้มบทความต้องชี้ไปหาผู้ใช้ที่มีอยู่จริง (foreign key — บท 115)

schema_migrations — สมุดเซ็นรับงานช่าง

คำถามต่อมา: สั่ง db:migrate ซ้ำสิบรอบ ทำไม Rails ไม่เพิ่มคอลัมน์ published ซ้ำสิบรอบ?
เพราะในฐานข้อมูลมีตารางลับอีกตัวชื่อ schema_migrations เก็บเลขประจำตัวของใบที่ทำไปแล้ว ใบละหนึ่งแถว · ก่อนทำใบไหน Rails เปิดดูตารางนี้ก่อน ถ้ามีเลขนั้นแล้วก็ข้าม

ดูข้างในด้วย console (bin/rails console) · บรรทัดนี้ยาวหน่อย เพราะ schema_migrations ไม่มี model ให้เรียกแบบ Post.all เลยต้องส่งคำสั่ง SQL ไปตรง ๆ (ผลจริง):

wongnok-blog(dev):001> ActiveRecord::Base.connection.execute("SELECT * FROM schema_migrations ORDER BY version").to_a
   (60.2ms)  SELECT * FROM schema_migrations ORDER BY version /*application='WongnokBlog'*/
=>
[{"version" => "20261104113601"},
 {"version" => "20261104113603"},
 {"version" => "20261104113604"},
 {"version" => "20261104113606"},
 {"version" => "20261104113607"}]

• ActiveRecord::Base.connection — สายตรงไปฐานข้อมูล · .execute("…") — ส่งคำสั่ง SQL ไปทั้งก้อน · .to_a — แปลงผลเป็น array ให้อ่านง่าย
• SELECT * FROM schema_migrations ORDER BY version — คำสั่ง SQL แปลเป็นภาษาคน: "ขอทุกช่อง (*) ของทุกแผ่น จากลิ้นชัก schema_migrations เรียงตามช่อง version จากน้อยไปมาก" · SELECT = ขอดู · FROM = จากลิ้นชักไหน · ORDER BY = เรียงตามอะไร
• บรรทัด (60.2ms) SELECT … — console โชว์ SQL ที่ยิงจริงพร้อมเวลา (ของคุณจะได้เลขอื่น) · ท่อน /*application='WongnokBlog'*/ คือป้ายที่ Rails แปะท้าย SQL บอกว่ามาจากแอปไหน ไม่ต้องสนใจ
• ผลคือ 5 แถว ช่องเดียวชื่อ version · ตัวเลขตรงกับหน้าชื่อไฟล์ทั้ง 5 ใบใน db/migrate/ = ทำครบทุกใบแล้ว

เทียบกับ Go: นี่คือตาราง goose_db_version ของ goose ในบท 31 นั่นเอง · ของ goose มีหลายช่อง (version_id · is_applied · tstamp) ส่วนของ Rails มีช่องเดียวคือ version — มีแถว = ทำแล้ว · ไม่มีแถว = ยังไม่ทำ

ลงมือ: เพิ่มคำโปรยใต้ชื่อบทความ

โจทย์: บทความแต่ละชิ้นอยากมี คำโปรยสั้น ๆ ใต้ชื่อเรื่อง เช่น "ต้มยำกุ้งน้ำข้น" — "สูตรเข้มข้นแบบร้านดัง" · ต้องเพิ่มคอลัมน์ subtitle (ข้อความสั้น) ในตาราง posts

ก่อนเริ่ม: commit ของที่ได้จากบท 107 ไว้ก่อน · ขั้น ③ จะใช้ git diff ดูว่า schema.rb เปลี่ยนตรงไหน ซึ่งเทียบกับ commit ล่าสุด — ถ้า schema.rb ยังไม่เคย commit มันจะไม่โชว์อะไรเลย (&& = ทำคำสั่งแรกสำเร็จแล้วค่อยทำคำสั่งถัดไป เหมือนบท 105):

$ git add . && git commit -m "schema และ seeds จากบท 107"
…(ผลของ commit ตัดออก)…
$ git status
On branch main
nothing to commit, working tree clean

nothing to commit, working tree clean = "ไม่มีอะไรค้าง ทุกอย่างบันทึกแล้ว" — ต่อจากนี้ทุกอย่างที่เปลี่ยนจะเห็นใน git diff · git status · (ถ้า git commit ตอบ nothing to commit ตั้งแต่แรก = คุณ commit ไว้แล้ว ไปต่อได้เลย · บรรทัด On branch main ของคุณอาจเป็น master ไม่ต่างกัน)

① ให้ Rails เขียนใบสั่งให้

$ bin/rails generate migration AddSubtitleToPosts subtitle:string
      invoke  active_record
      create    db/migrate/20261104114634_add_subtitle_to_posts.rb

• generate migration — "เขียนใบสั่งช่างเปล่า ๆ ให้หนึ่งใบ" · เหมือน generate model ในบท 99 แต่สร้างแค่ไฟล์ migration ไฟล์เดียว
• AddSubtitleToPosts — ชื่อใบ · ตั้งชื่อตามแบบ Add…To… แล้ว Rails เดาเนื้อหาให้: Add = เพิ่มคอลัมน์ · ToPosts = ในตาราง posts
• subtitle:string — ชื่อคอลัมน์ : ชนิดข้อมูล (string = ข้อความสั้น)
• invoke active_record — Rails บอกว่า "ส่งงานให้ส่วน Active Record (บท 106) เป็นคนเขียนไฟล์" · ไม่ต้องทำอะไร
• create db/migrate/20261104114634_… — ได้ไฟล์ใหม่ เลขข้างหน้าคือเวลาที่คุณสั่ง

เปิดไฟล์ที่ได้ — Rails เขียนเนื้อหาให้ครบแล้ว ไม่ต้องพิมพ์อะไรเพิ่ม:

# db/migrate/20261104114634_add_subtitle_to_posts.rb
class AddSubtitleToPosts < ActiveRecord::Migration[8.1]
  def change
    add_column :posts, :subtitle, :string
  end
end

ตอนนี้ มีแค่ใบสั่ง ยังไม่มีช่างลงมือ · ฐานข้อมูลยังไม่มีคอลัมน์ subtitle · และ schema.rb ยังไม่เปลี่ยนสักตัวอักษร

$ bin/rails db:migrate:status

database: w108

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20261104113601  Create posts
   up     20261104113603  Add published and views to posts
   up     20261104113604  Create users
   up     20261104113606  Add user to posts
   up     20261104113607  Create comments
  down    20261104114634  Add subtitle to posts

② สั่งช่างลงมือ: db:migrate

$ bin/rails db:migrate
== 20261104114634 AddSubtitleToPosts: migrating ===============================
-- add_column(:posts, :subtitle, :string)
   -> 0.0033s
== 20261104114634 AddSubtitleToPosts: migrated (0.0033s) ======================

• == … migrating — เริ่มทำใบนี้ · ทำแค่ใบที่ down อีก 5 ใบที่ up แล้วข้ามไปเงียบ ๆ
• -- add_column(…) — คำสั่งที่ทำ · -> 0.0033s — ใช้เวลา 0.0033 วินาที (ตารางเล็กมาก เลยเร็ว — ตารางที่มีเป็นล้านแถวจะเป็นอีกเรื่อง บท 109)
• migrated — เสร็จ · Rails จดเลข 20261104114634 ลง schema_migrations แล้วเขียน schema.rb ใหม่ให้ทันที

③ แปลนตู้เปลี่ยนตรงไหน

ใช้ git diff ดูว่า schema.rb ต่างจากก่อน migrate ยังไง (ผลจริง ตัดบรรทัดที่ไม่เปลี่ยนรอบ ๆ ออกบางส่วน):

$ git diff db/schema.rb
-ActiveRecord::Schema[8.1].define(version: 2026_11_04_113607) do
+ActiveRecord::Schema[8.1].define(version: 2026_11_04_114634) do
…
     t.boolean "published", default: false, null: false
     t.integer "views", default: 0, null: false
     t.bigint "user_id", null: false
+    t.string "subtitle"
     t.index ["user_id"], name: "index_posts_on_user_id"
   end

• git diff ไฟล์ = ดูว่าไฟล์ต่างจากตอน commit ล่าสุดตรงไหน · บรรทัดขึ้นต้น - = ของเดิมที่หายไป · + = ของใหม่
• version เลื่อนจาก …113607 เป็น …114634 = ใบล่าสุดคือใบ subtitle
• + t.string "subtitle" — คอลัมน์ใหม่ต่อท้ายตาราง posts · มีสองบรรทัดนี้เท่านั้น = ตรงกับที่ตั้งใจ พร้อม commit

เช็คสถานะอีกรอบ — ใบ subtitle กลายเป็น up (ผลจริง ตัดบรรทัดบนออก):

$ bin/rails db:migrate:status
…
   up     20261104113607  Create comments
   up     20261104114634  Add subtitle to posts

④ เรียกช่างมารื้อ: db:rollback

$ bin/rails db:rollback
== 20261104114634 AddSubtitleToPosts: reverting ===============================
-- remove_column(:posts, :subtitle, :string)
   -> 0.0040s
== 20261104114634 AddSubtitleToPosts: reverted (0.0046s) ======================

• reverting — กำลังย้อนใบล่าสุด (ใบเดียว)
• remove_column(:posts, :subtitle, :string) — เราไม่ได้เขียนบรรทัดนี้ Rails กลับด้าน add_column ใน change ให้เอง
• reverted — เสร็จ · Rails ลบเลขใบนี้ออกจาก schema_migrations และเขียน schema.rb ใหม่ (บรรทัด subtitle หายไป git diff กลับมาว่างเปล่า)

สถานะตอนนี้กลับเป็น down — ไฟล์ยังอยู่ แค่ยังไม่ได้ทำ (ผลจริง):

$ bin/rails db:migrate:status
…
   up     20261104113607  Create comments
  down    20261104114634  Add subtitle to posts

คลังคำที่เขียนใน change ได้

ไม่ต้องจำ — ให้รู้ว่ามีคำอะไรบ้าง แล้วกลับมาเปิดตารางนี้ (หรือ cheat sheet) ตอนใช้:

สไลด์หน้า 14 มีคำอื่นอีก เช่น rename_table (เปลี่ยนชื่อลิ้นชัก) · remove_index (แกะป้ายสารบัญออก) — ไม่ต้องจำตอนนี้ · คำที่ใช้ตั้งกฎให้ตัวตู้ (เช่น "ช่องนี้ห้ามว่าง") จะได้ใช้จริงในบท 111

และชื่อใบแบบไหน generator เดาเนื้อหาให้ได้ — ผมลองสั่งทีละแบบ (ผลจริง ตัดมาเฉพาะบรรทัดใน change):

แถวสุดท้ายสำคัญ: ชื่อผิดแบบ generator ไม่ฟ้อง แค่ให้ใบเปล่า · ถ้าไม่เปิดดูแล้วสั่ง migrate ไปเลย ก็จะ "สำเร็จ" โดยไม่ได้เพิ่มอะไร · เปิดไฟล์ดูทุกครั้งหลัง generate · (ส่วน AddSubtitleToPost ที่ลืม s ไม่เป็นไร ผมลองแล้ว Rails ยังเติม :posts ให้ถูก)

คำสั่ง db: ที่ใช้บ่อย และอันไหนห้ามแตะบนร้านจริง

วิธีจำง่าย ๆ: production คือร้านจริงที่ลูกค้ากำลังนั่งกินอยู่ · คำสั่งไหน "รื้อ" หรือ "ล้าง" ห้ามทำบนร้านจริง · บนร้านจริงถ้าใบสั่งผิด ให้เขียนใบใหม่มาแก้ ไม่ย้อนใบเก่า (กับดักท้ายบท)

เพื่อนใหม่เข้าทีม: ทำไม schema.rb ต้อง commit

เพื่อนใหม่ clone โปรเจกต์ไป เครื่องเขามีไฟล์ครบ แต่ฐานข้อมูลยังว่างเปล่า · สไลด์หน้า 12 บอกว่า bin/rails db:prepare จบ — จริง · ผมลองกับฐานข้อมูลใหม่เอี่ยม (ผลจริง):

$ bin/rails db:prepare
Created database 'w108_new'

ขึ้นบรรทัดเดียว — ไม่มีบรรทัด == … migrating สักใบ (w108_new คือชื่อฐานข้อมูลทดลองของผม) · แต่ตารางครบ status ขึ้น up ทั้ง 5 ใบ และข้อมูลตัวอย่างครบ (นับด้วย bin/rails runner แบบบท 107 ได้ users 3 · posts 6 · comments 7)

เพราะบนฐานข้อมูลใหม่ Rails ไม่ไล่ทำใบสั่งทีละใบ แต่สร้างตู้ตามแปลน schema.rb ทีเดียว · จดเลขทุกใบลงสมุดให้ แล้วค่อยรัน seeds

# ฐานข้อมูลใหม่อีกก้อน คราวนี้สั่งแยกทีละขั้น
$ bin/rails db:create
Created database 'w108_new'
$ bin/rails db:migrate

กับดัก: แก้ไฟล์ migration ที่รันไปแล้ว

สมมติเราสั่ง db:migrate ให้ใบ subtitle กลับมาเป็น up แล้ว · จากนั้นนึกได้ว่า "อยากให้ค้นหาตาม subtitle ได้เร็วด้วย" มือใหม่ส่วนใหญ่จะเปิดไฟล์เดิมแล้วเติมบรรทัด add_index ลงไป:

# db/migrate/20261104114634_add_subtitle_to_posts.rb — แก้หลังจาก migrate ไปแล้ว
class AddSubtitleToPosts < ActiveRecord::Migration[8.1]
  def change
    add_column :posts, :subtitle, :string
    add_index :posts, :subtitle      # ← เติมบรรทัดนี้
  end
end

$ bin/rails db:migrate

แย่กว่านั้น: ถ้าคิดว่า "งั้น rollback แล้ว migrate ใหม่" ตอนนี้เลย — rollback พัง (ผลจริง ตัดบรรทัดที่ไม่จำเป็นเป็น …):

$ bin/rails db:rollback
== 20261104114634 AddSubtitleToPosts: reverting ===============================
-- remove_index(:posts, :subtitle)
bin/rails aborted!
StandardError: An error has occurred, this and all later migrations canceled: (StandardError)

No indexes found on posts with the options provided.
…
Tasks: TOP => db:rollback

• Rails ย้อนตามไฟล์ที่แก้แล้ว: บรรทัดสุดท้ายคือ add_index → ขากลับคือ remove_index → ทำก่อน
• แต่ index นั้นไม่เคยถูกสร้างจริง (ข้อที่แล้ว) → No indexes found on posts = "หา index ใน posts ไม่เจอ"
• bin/rails aborted! — คำสั่งหยุดกลางทาง · this and all later migrations canceled — ยกเลิกทั้งใบ ไม่มีอะไรเปลี่ยน · ใบยังเป็น up ค้างอยู่
• Tasks: TOP => db:rollback — บรรทัดท้ายบอกแค่ว่าพังระหว่างคำสั่ง db:rollback · ใจความอยู่บรรทัด No indexes found… ข้างบน

วิธีที่ถูก มีสองทาง เลือกตามว่าใบนี้ไปถึงใครแล้ว (ทั้งสองทางเริ่มจากไฟล์ใบเดิมที่ยังไม่ได้แก้):

$ bin/rails db:rollback      # ไฟล์ยังเป็นแบบเดิม → ผ่าน
# ค่อยเติม add_index ในไฟล์
$ bin/rails db:migrate
== 20261104114634 AddSubtitleToPosts: migrating ===
-- add_column(:posts, :subtitle, :string)
   -> 0.0021s
-- add_index(:posts, :subtitle)
   -> 0.0025s
== 20261104114634 AddSubtitleToPosts: migrated (0.0047s) ===

$ bin/rails generate migration AddIndexToPostsSubtitle
      create    db/migrate/20261104115037_add_index_to_posts_subtitle.rb
# ได้ change เปล่า → พิมพ์ add_index :posts, :subtitle เอง
$ bin/rails db:migrate
== 20261104115037 AddIndexToPostsSubtitle: migrating ===
-- add_index(:posts, :subtitle)
   -> 0.0063s
== 20261104115037 AddIndexToPostsSubtitle: migrated (0.0063s) ===

(ผลทั้งสองฝั่งรันจริง · ผมตัดเส้น ===== ท้ายบรรทัดให้สั้นลง และตัดบรรทัด invoke active_record ออก เพื่อให้พอดีกล่อง · ชื่อ AddIndexToPostsSubtitle ไม่ตรงแบบที่ generator เดาได้ จึงได้ใบเปล่า ต้องพิมพ์บรรทัดเอง)

เก็บกวาดก่อนไปบทหน้า

บทหลังจากนี้ใช้ตาราง posts แบบเดิม (ไม่มี subtitle) · ดูก่อนว่าคุณหยุดอยู่ตรงไหน:

• ทำแค่ถึงขั้น ④ (ใบ subtitle เป็น down อยู่) → สั่ง bin/rails destroy migration AddSubtitleToPosts คำสั่งเดียวพอ
• ทำวิธีที่ ② มาจนมีสองใบใหม่ → ย้อนสองใบแล้วลบไฟล์ทิ้ง ตามนี้ (ผลจริง):

$ bin/rails db:rollback STEP=2
== 20261104115037 AddIndexToPostsSubtitle: reverting ==========================
-- remove_index(:posts, :subtitle)
   -> 0.0069s
== 20261104115037 AddIndexToPostsSubtitle: reverted (0.0083s) =================

== 20261104114634 AddSubtitleToPosts: reverting ===============================
-- remove_column(:posts, :subtitle, :string)
   -> 0.0027s
== 20261104114634 AddSubtitleToPosts: reverted (0.0028s) ======================

$ bin/rails destroy migration AddIndexToPostsSubtitle
      invoke  active_record
      remove    db/migrate/20261104115037_add_index_to_posts_subtitle.rb
$ bin/rails destroy migration AddSubtitleToPosts
      invoke  active_record
      remove    db/migrate/20261104114634_add_subtitle_to_posts.rb

• STEP=2 — ย้อนสองใบล่าสุด · ย้อนจากใบใหม่สุดก่อน (index ออกก่อน แล้วค่อยรื้อคอลัมน์)
• destroy migration ชื่อ — ตรงข้ามกับ generate: ลบไฟล์ที่ generate สร้าง (เหมือน destroy model ในบท 99)
• ลำดับต้องเป็น rollback ก่อน แล้วค่อย destroy · สลับกัน = ลบใบสั่งทิ้งทั้งที่ช่างยังไม่ได้รื้อ (ดูในภารกิจ)
• ถ้าคุณทำวิธีที่ ① (มีใบเดียวที่มีทั้ง add_column และ add_index) ให้สั่ง bin/rails db:rollback ครั้งเดียว แล้ว bin/rails destroy migration AddSubtitleToPosts
• เสร็จแล้ว git status ต้องว่าง · db:migrate:status เหลือ up 5 ใบเหมือนตอนเริ่ม

ถ้าเปิดสไลด์ดูประกอบ

อ้างอิง

• Rails Guides — Active Record Migrations § Generating Migration Files — อ่านหัวข้อย่อย Adding Columns กับ Removing Columns · ยืนยันว่าชื่อ AddXToY / RemoveXFromY ทำให้ generator เขียนเนื้อหาให้
• Rails Guides — § Rails Migration Version Control — ย่อหน้าสั้น ๆ อธิบายว่า schema_migrations เก็บเลขจากชื่อไฟล์ · อ่านต่อ § Changing Existing Migrations ที่บอกตรง ๆ ว่าแก้ไฟล์ที่รันแล้ว Rails "will do nothing" และควรเขียนใบใหม่
• Rails Guides — § Preparing the Database และ § Schema Dumps and Source Control — db:prepare บนฐานข้อมูลใหม่ทำอะไร และทำไม "strongly recommended" ให้ commit schema.rb
• Rails — activerecord/CHANGELOG.md (v8.0.0) — ค้นคำว่า "fresh database" · บรรทัดที่ยืนยันว่า db:migrate บนฐานข้อมูลใหม่โหลด schema ก่อน (เหตุผลที่ predict ข้างบนจอว่าง)
• Rails API — SchemaStatements — รายการคำที่ใช้ใน change ครบทุกตัว · ดูแค่ add_column · remove_column · rename_column · add_index พอ
• pressly/goose (GitHub) — เครื่องมือ migration ของ Go ที่ใช้ในบท 31 · ดูตัวอย่างไฟล์ -- +goose Up / Down ใน README เทียบกับ change ของ Rails