ลบบทความแล้วคอมเมนต์ไปไหน — dependent, CASCADE และ counter_cache

ลองลบบทความที่มีคอมเมนต์ — แล้วตู้ไม่ยอม

เปิดครัวทดลองด้วย bin/rails console แล้วลองทิ้งบทความต้มยำกุ้ง (ที่มีคนคอมเมนต์ไว้ 2 ใบ) ด้วย destroy แบบที่เรียนในบท 107:

wongnok-blog(dev):001> post = Post.find_by(title: "ต้มยำกุ้งน้ำข้น")
  Post Load (1.6ms)  SELECT "posts".* FROM "posts" WHERE "posts"."title" = 'ต้มยำกุ้งน้ำข้น' LIMIT 1 /*application='WongnokBlog'*/
=> #<Post … (ผลยาว ตัดออก)
wongnok-blog(dev):002> post.comments.count
  Comment Count (1.8ms)  SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 1 /*application='WongnokBlog'*/
=> 2
wongnok-blog(dev):003> post.destroy
  TRANSACTION (1.9ms)  BEGIN /*application='WongnokBlog'*/
  Post Destroy (5.6ms)  DELETE FROM "posts" WHERE "posts"."id" = 1 /*application='WongnokBlog'*/
  TRANSACTION (0.7ms)  ROLLBACK /*application='WongnokBlog'*/
(wongnok-blog):3:in '<main>': PG::ForeignKeyViolation: ERROR:  update or delete on table "posts" violates foreign key constraint "fk_rails_2fd19c0db7" on table "comments" (ActiveRecord::InvalidForeignKey)
DETAIL:  Key (id)=(1) is still referenced from table "comments".

… (ข้อความเดิมซ้ำอีกรอบจากชั้นในของ PostgreSQL ตามด้วยรายชื่อไฟล์ยาว ๆ และ "... 55 levels..." — ข้ามได้)

อ่าน log ทีละบรรทัด (บรรทัดที่ย่อหน้าเข้าไปคือ SQL ที่ Rails ยิงไปที่ตู้ · คำหน้าสุด เช่น Post Destroy บอกว่างานของใคร):

• BEGIN — เริ่ม transaction: "งานต่อจากนี้ ทำทั้งชุดหรือไม่ทำเลย"
• DELETE FROM "posts" WHERE "posts"."id" = 1 — DELETE คือคำสั่ง "ทิ้ง" · แปลว่า "ทิ้งแฟ้มจากลิ้นชัก posts เฉพาะแผ่นที่เลขที่ (id) เป็น 1" · สังเกตว่า Rails ไม่ได้เช็คอะไรก่อนเลย ส่งคำสั่งทิ้งไปตรง ๆ
• ROLLBACK — ตู้ปฏิเสธ Rails เลยยกเลิกทั้งชุด · ไม่มีอะไรหาย บทความยังอยู่ครบ

แล้วอ่าน error ทีละท่อน:

สรุปเป็นภาษาคน: ถ้าทิ้งบทความเลขที่ 1 ไป ใบคอมเมนต์ 2 ใบที่เขียนว่า "เป็นของบทความเลขที่ 1" จะชี้ไปหาของที่ไม่มีอยู่จริง ตู้เลยไม่ยอม
กฎนี้มาจาก foreign_key: true ตอนสร้างตาราง comments (post:references ในบท 107) — ตัวเดียวกับที่บท 111 ใช้กันใบคอมเมนต์ที่ชี้ไปบทความเลข 9999 · บท 111 เห็นด้าน "เพิ่มใบลูกที่ไม่มีแม่" · บทนี้เห็นอีกด้าน "ทิ้งแม่ที่ยังมีลูก"

เทียบกับ Go: ถ้าเขียน db.Delete(&post) ด้วย GORM (บท 27) กับตารางที่มี foreign key แบบนี้ ก็ถูกตู้ปฏิเสธด้วยกฎเดียวกัน — เพราะคนปฏิเสธคือ PostgreSQL ไม่ใช่ Rails · ภาษาไหนมาต่อตู้นี้ก็โดนกฎเดียวกันหมด (ฝั่ง Go จะได้ error กลับมาเป็นค่า err แทนการระเบิด)

post = Post.find_by(title: "ก๋วยเตี๋ยวเรืออยุธยา")
post.comments.count    # => 0
post.destroy

wongnok-blog(dev):003> post.destroy
  TRANSACTION (2.1ms)  BEGIN /*application='WongnokBlog'*/
  Post Destroy (4.1ms)  DELETE FROM "posts" WHERE "posts"."id" = 4 /*application='WongnokBlog'*/
  TRANSACTION (1.6ms)  COMMIT /*application='WongnokBlog'*/
=> #<Post … (ผลยาว ตัดออก)
wongnok-blog(dev):004> Post.count
  Post Count (2.7ms)  SELECT COUNT(*) FROM "posts" /*application='WongnokBlog'*/
=> 5

สี่ทางเลือก — ภาพรวมก่อนลงมือ

Rails ไม่เดาให้ว่าลบบทความแล้วคอมเมนต์ควรเป็นยังไง เพราะคำตอบขึ้นกับธุรกิจ · เราต้องเลือกเองหนึ่งในสี่แบบนี้ แล้วเขียนบอกไว้ในโค้ด (สามแบบเขียนใน model · หนึ่งแบบเขียนใน migration)

เราจะลองทีละแบบกับบทความต้มยำกุ้ง แล้วดูว่า Rails ยิง SQL อะไรจริง · ก่อนเริ่ม ให้แปะ callback (ขั้นตอนอัตโนมัติ จากบท 112) ไว้ที่ใบคอมเมนต์ ชั่วคราว — เพื่อให้เห็นด้วยตาว่าแบบไหน "จดบันทึก" แบบไหนไม่จด (เพิ่มแค่บรรทัด after_destroy · กฎอื่นที่คุณเติมไว้จากบทก่อน ๆ คงไว้ตามเดิม):

# app/models/comment.rb
class Comment < ApplicationRecord
  belongs_to :post
  belongs_to :user

  after_destroy { puts "📝 จดบันทึก: ทิ้งใบคอมเมนต์เลขที่ #{id} แล้ว" }
end

• after_destroy — callback แบบที่ทำงานหลังจากใบนี้ถูกทิ้ง (ญาติของ after_commit ในบท 112)
• { puts "…" } — block (บท 93) ที่พิมพ์ข้อความออกจอ · #{id} = แทรกเลขที่ของใบนี้ลงในข้อความ
• ในงานจริงตรงนี้อาจเป็น "ลบรูปที่แนบมากับคอมเมนต์" หรือ "หักแต้มผู้ใช้" — งานที่ต้องเกิดทุกครั้งที่ใบคอมเมนต์หายไป

ทางที่ ① — dependent: :destroy ทิ้งทีละใบ พร้อมจดบันทึก

บอก Rails ว่า "ก่อนทิ้งบทความ ให้ทิ้งใบคอมเมนต์ของมันให้หมดก่อน แบบทีละใบ" · เติมแค่ท้ายบรรทัด has_many :comments (บรรทัดอื่นในไฟล์ของคุณ เช่น has_many :taggings จากบท 115 คงไว้):

# app/models/post.rb
class Post < ApplicationRecord
  belongs_to :user
  has_many :comments, dependent: :destroy
end

dependent: แปลว่า "ของที่พึ่งพาแฟ้มนี้" · :destroy คือวิธีจัดการ · แก้ไฟล์แล้วต้องสั่ง reload! ใน console (หรือปิดแล้วเปิดใหม่ — บท 104) แล้วหาบทความใหม่อีกรอบ เพราะตัวแปร post เก่ายังจำกฎเก่าอยู่:

wongnok-blog(dev):001> post = Post.find_by(title: "ต้มยำกุ้งน้ำข้น")
  Post Load (1.5ms)  SELECT "posts".* FROM "posts" WHERE "posts"."title" = 'ต้มยำกุ้งน้ำข้น' LIMIT 1 /*application='WongnokBlog'*/
=> #<Post … (ผลยาว ตัดออก)
wongnok-blog(dev):002> post.destroy
  TRANSACTION (1.4ms)  BEGIN /*application='WongnokBlog'*/
  Comment Load (1.3ms)  SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = 1 /*application='WongnokBlog'*/
  Comment Destroy (1.3ms)  DELETE FROM "comments" WHERE "comments"."id" = 1 /*application='WongnokBlog'*/
📝 จดบันทึก: ทิ้งใบคอมเมนต์เลขที่ 1 แล้ว
  Comment Destroy (0.9ms)  DELETE FROM "comments" WHERE "comments"."id" = 2 /*application='WongnokBlog'*/
📝 จดบันทึก: ทิ้งใบคอมเมนต์เลขที่ 2 แล้ว
  Post Destroy (1.2ms)  DELETE FROM "posts" WHERE "posts"."id" = 1 /*application='WongnokBlog'*/
  TRANSACTION (1.9ms)  COMMIT /*application='WongnokBlog'*/
=> #<Post … (ผลยาว ตัดออก)
wongnok-blog(dev):003> Comment.count
  Comment Count (2.7ms)  SELECT COUNT(*) FROM "comments" /*application='WongnokBlog'*/
=> 5

• Comment Load … SELECT "comments".* … WHERE "comments"."post_id" = 1 — "หยิบใบคอมเมนต์ทุกใบของบทความเลขที่ 1 ออกมาก่อน" (เอาขึ้นมาเป็น object ใน Ruby)
• DELETE FROM "comments" WHERE "comments"."id" = 1 — ทิ้งใบเลขที่ 1 → ตามด้วย 📝 = callback ของใบนั้นทำงาน
• ทำซ้ำกับใบเลขที่ 2 · หนึ่งใบ = หนึ่งคำสั่ง DELETE
• ลูกหมดแล้ว ค่อย DELETE FROM "posts" … = 1 · ตู้ยอม → COMMIT · คอมเมนต์ทั้งร้านเหลือ 5 จาก 7

ราคาที่จ่ายคือจำนวนคำสั่ง — ผมลองบทความที่มีคอมเมนต์ 100 ใบ แล้วนับ SQL ตอน destroy ได้ 104 คำสั่ง (BEGIN 1 · หยิบคอมเมนต์ 1 · DELETE ทีละใบ 100 · DELETE บทความ 1 · COMMIT 1) · คอมเมนต์ 5,000 ใบก็ราว 5,000 กว่าคำสั่ง ช้าตามจำนวนลูก

เทียบกับ Go: GORM มีท่าที่ใกล้เคียง คือบอกตอนลบว่าให้ลบลูกชื่ออะไรไปด้วย (ต้องเขียนทุกครั้งที่ลบ ไม่ได้ประกาศไว้ที่ struct ครั้งเดียวแบบ Rails):

// Go + GORM — ลบบทความพร้อม Comments ของมัน (ตามเอกสาร GORM หัวข้อ Delete Associations)
db.Select("Comments").Delete(&post)

Select("Comments") ตรงนี้ไม่ได้แปลว่า "ค้นหา" — แปลว่า "เลือกลูกชื่อ Comments (ชื่อ field ใน struct Post) ให้ลบตามไปด้วย" · ไม่ใส่ = GORM ลบแค่บทความ แล้วโดนตู้ปฏิเสธแบบต้นบท

ทดลองเสร็จ สั่ง exit ออกจาก console แล้ว bin/rails db:reset ให้ต้มยำกุ้งกลับมา ก่อนไปทางที่ ②

ทางที่ ② — dependent: :delete_all โกยทิ้งทั้งกอง

เปลี่ยนคำเดียวใน app/models/post.rb (callback 📝 ของ Comment ยังอยู่เหมือนเดิม):

  has_many :comments, dependent: :delete_all

post = Post.find_by(title: "ต้มยำกุ้งน้ำข้น")
post.destroy

wongnok-blog(dev):002> post.destroy
  TRANSACTION (1.7ms)  BEGIN /*application='WongnokBlog'*/
  Comment Delete All (1.1ms)  DELETE FROM "comments" WHERE "comments"."post_id" = 1 /*application='WongnokBlog'*/
  Post Destroy (0.9ms)  DELETE FROM "posts" WHERE "posts"."id" = 1 /*application='WongnokBlog'*/
  TRANSACTION (1.0ms)  COMMIT /*application='WongnokBlog'*/
=> #<Post … (ผลยาว ตัดออก)
wongnok-blog(dev):003> Comment.count
  Comment Count (1.8ms)  SELECT COUNT(*) FROM "comments" /*application='WongnokBlog'*/
=> 5

ใน Go ท่านี้คือการเขียนลบลูกด้วยเงื่อนไขเองก่อน แล้วค่อยลบแม่ — Rails แค่เขียนสองบรรทัดนี้ให้อัตโนมัติ:

// Go + GORM — สิ่งที่ dependent: :delete_all ทำให้ ถ้าเขียนเอง
db.Where("post_id = ?", post.ID).Delete(&Comment{})  // DELETE FROM comments WHERE post_id = …
db.Delete(&post)

ทดลองเสร็จ exit แล้ว bin/rails db:reset อีกรอบ

ทางที่ ③ — on_delete: :cascade ให้ตู้ทิ้งเอง

สองทางแรก Rails เป็นคนลบ · ทางนี้ย้ายงานไปให้ตัวตู้ (PostgreSQL) — เราแก้กฎ foreign key เดิมจาก "ห้ามทิ้งแม่ที่มีลูก" เป็น "ทิ้งแม่แล้วให้ลูกหายตาม" · การแก้กฎของตู้ = แก้โครงตู้ → ต้องเขียน migration (ใบสั่งช่าง บท 108)

เริ่มจากเอา dependent: ออกจาก Post ก่อน (ให้เห็นผลของตู้ล้วน ๆ):

  has_many :comments

แล้วสร้างใบสั่งช่างเปล่า ๆ หนึ่งใบ (ชื่อ migration ตั้งเองได้ ขอให้อ่านแล้วรู้ว่าทำอะไร):

$ bin/rails generate migration ChangeCommentsPostForeignKeyToCascade
      invoke  active_record
      create    db/migrate/20261104120515_change_comments_post_foreign_key_to_cascade.rb

ตัวเลขหน้าชื่อไฟล์คือวันเวลาที่สร้าง — ของคุณจะต่าง · เปิดไฟล์นั้น แล้วเขียนข้างใน change สองบรรทัด:

# db/migrate/20261104120515_change_comments_post_foreign_key_to_cascade.rb
class ChangeCommentsPostForeignKeyToCascade < ActiveRecord::Migration[8.1]
  def change
    remove_foreign_key :comments, :posts
    add_foreign_key :comments, :posts, on_delete: :cascade
  end
end

• remove_foreign_key :comments, :posts — "รื้อกฎเดิมที่ผูกลิ้นชัก comments ไว้กับลิ้นชัก posts ออก" (กฎของตู้แก้ตรง ๆ ไม่ได้ ต้องรื้อแล้วติดใหม่)
• add_foreign_key :comments, :posts, on_delete: :cascade — "ติดกฎใหม่ ที่เวลาทิ้งแฟ้มบทความ ให้ทิ้งใบคอมเมนต์ที่อ้างถึงตามไปด้วย" · on_delete = "เมื่อมีการทิ้ง" · :cascade = "ไหลต่อเป็นทอด ๆ" (แบบน้ำตก)

$ bin/rails db:migrate
== 20261104120515 ChangeCommentsPostForeignKeyToCascade: migrating ============
-- remove_foreign_key(:comments, :posts)
   -> 0.0095s
-- add_foreign_key(:comments, :posts, {on_delete: :cascade})
   -> 0.0041s
== 20261104120515 ChangeCommentsPostForeignKeyToCascade: migrated (0.0136s) ===

เปิดแปลนตู้ฉบับล่าสุด (db/schema.rb) จะเห็นบรรทัดกฎของ comments เปลี่ยนไปหนึ่งบรรทัด (แสดงแบบ git diff — บรรทัด - คือของเดิม · + คือของใหม่ · นอกจากนี้เลข version: บรรทัดบนสุดก็เปลี่ยนเป็นเลขของ migration ใหม่ตามปกติ):

-  add_foreign_key "comments", "posts"
+  add_foreign_key "comments", "posts", on_delete: :cascade

migration นี้ย้อนได้ด้วย bin/rails db:rollback — ผมลองแล้ว Rails รื้อกฎ cascade ออกแล้วติดกฎเดิมกลับให้เอง (เพราะเราบอกชื่อลิ้นชักทั้งสองฝั่งไว้ครบ มันเลยรู้ว่าต้องติดอะไรคืน) · ถ้าลอง rollback ดู ให้สั่ง bin/rails db:migrate กลับก่อนไปต่อ · ทีนี้ bin/rails db:reset แล้วเปิด console ทิ้งต้มยำกุ้ง:

wongnok-blog(dev):001> post = Post.find_by(title: "ต้มยำกุ้งน้ำข้น")
  … (Post Load — ตัดออก)
wongnok-blog(dev):002> post.destroy
  TRANSACTION (2.4ms)  BEGIN /*application='WongnokBlog'*/
  Post Destroy (5.2ms)  DELETE FROM "posts" WHERE "posts"."id" = 1 /*application='WongnokBlog'*/
  TRANSACTION (2.0ms)  COMMIT /*application='WongnokBlog'*/
=> #<Post … (ผลยาว ตัดออก)
wongnok-blog(dev):003> Comment.count
  Comment Count (1.1ms)  SELECT COUNT(*) FROM "comments" /*application='WongnokBlog'*/
=> 5

เทียบกับต้นบทดี ๆ: SQL ที่ Rails ยิงเหมือนกันทุกตัวอักษร (DELETE FROM "posts" WHERE "posts"."id" = 1) — ต่างกันแค่คราวนี้ตู้ตอบ COMMIT
คอมเมนต์ 2 ใบหายไปจริง (เหลือ 5) แต่ log ไม่มีบรรทัดไหนพูดถึงคอมเมนต์เลย และไม่มี 📝 — ตู้ทิ้งเองข้างใน Rails ไม่รู้เรื่อง

ข้อดีที่สองทางแรกให้ไม่ได้: กฎนี้อยู่ในตู้ ใครมาทิ้งแฟ้มทางไหนก็โดน — ผมลองสั่ง SQL ตรง ๆ DELETE FROM posts WHERE id = 5 โดยไม่ผ่าน model ใบคอมเมนต์ของบทความ 5 ก็หายตามครบ · นี่คือแนวคิดเดียวกับบท 111: กฎใน model ข้ามได้ กฎในตู้ข้ามไม่ได้

ทดลองเสร็จ exit แล้ว bin/rails db:reset ให้บทความกลับมาครบ 6 ชิ้น (กฎ cascade ยังอยู่ เพราะอยู่ในแปลนตู้แล้ว)

เทียบกับ Go: กฎนี้เป็นของ PostgreSQL ล้วน ๆ จึงเขียนได้ทั้งใน SQL ของ goose (บท 31) และใน tag ของ GORM:

-- goose (SQL ล้วน) — คำว่า ON DELETE CASCADE ตัวเดียวกับที่ Rails สร้างให้
post_id BIGINT NOT NULL REFERENCES posts(id) ON DELETE CASCADE

// GORM — บอกผ่าน tag บน struct (ตามเอกสาร GORM หัวข้อ Foreign Key Constraint)
Comments []Comment `gorm:"constraint:OnDelete:CASCADE;"`

• บรรทัด goose แปลว่า "ช่อง post_id เป็นเลขจำนวนเต็ม (BIGINT) · ห้ามว่าง (NOT NULL) · ต้องตรงกับ id ที่มีอยู่จริงในลิ้นชัก posts (REFERENCES posts(id)) · และเมื่อแฟ้มบทความถูกทิ้ง ให้ทิ้งใบนี้ตาม (ON DELETE CASCADE)"
• บรรทัด GORM คือ field Comments ใน struct Post พร้อม tag ที่บอกว่า "ตอน AutoMigrate สร้างตาราง (บท 27) ให้ติดกฎ cascade ด้วย"

ทางที่ ④ — dependent: :restrict_with_error ห้ามทิ้ง

บางธุรกิจไม่อยากให้ลบเลยถ้ายังมีของอ้างอยู่ — เช่น ห้ามลบหมวดหมู่ที่ยังมีบทความ (สไลด์หน้า 54 ใช้ตัวนี้กับ Category) · ต่างจากต้นบทตรงที่คราวนี้ Rails เป็นคนห้ามเอง อย่างสุภาพ ก่อนจะไปถึงตู้ · ลองกับ Post:

  has_many :comments, dependent: :restrict_with_error

wongnok-blog(dev):001> post = Post.find_by(title: "ต้มยำกุ้งน้ำข้น")
  … (Post Load — ตัดออก)
wongnok-blog(dev):002> post.destroy
  TRANSACTION (2.5ms)  BEGIN /*application='WongnokBlog'*/
  Comment Exists? (1.7ms)  SELECT 1 AS one FROM "comments" WHERE "comments"."post_id" = 1 LIMIT 1 /*application='WongnokBlog'*/
  TRANSACTION (1.2ms)  ROLLBACK /*application='WongnokBlog'*/
=> false
wongnok-blog(dev):003> post.errors.full_messages
=> ["Cannot delete record because dependent comments exist"]
wongnok-blog(dev):004> Post.count
  Post Count (3.2ms)  SELECT COUNT(*) FROM "posts" /*application='WongnokBlog'*/
=> 6

• SELECT 1 AS one FROM "comments" WHERE "comments"."post_id" = 1 LIMIT 1 — "ไม่ต้องหยิบแฟ้มมา แค่บอกว่ามีใบคอมเมนต์ของบทความ 1 สักใบไหม" (LIMIT 1 = เจอใบแรกก็หยุด · คำสั่งเดียวกับ exists? ในบท 113)
• เจอ → ไม่ส่ง DELETE เลย แล้ว ROLLBACK · destroy คืน false (เหมือน save ที่คืน false ในบท 110)
• errors.full_messages — "ลบไม่ได้ เพราะยังมี comments ที่พึ่งพาอยู่" · ข้อความนี้เอาไปโชว์บนหน้าเว็บได้เลย ไม่ต้องหน้าแดง

อยากให้ระเบิดแทนคืน false ก็ใช้ destroy! ตามกฎ ! ของบท 110 — ผลจริง: Failed to destroy Post with id=1 (ActiveRecord::RecordNotDestroyed)

เลือกแบบไหน — คำตอบมาจากธุรกิจ ไม่ใช่จาก AI

ทั้งสี่แบบ "ถูก" ทางเทคนิคหมด · ที่ต่างคือธุรกิจอยากให้เกิดอะไร — คำถามแบบนี้ AI ตอบแทนไม่ได้ เพราะมันไม่รู้กฎของร้านคุณ (ถ้าไม่บอก มันก็ได้แต่เดา) · ถามคนที่รู้เรื่องธุรกิจด้วยคำถามในคอลัมน์ซ้าย:

ตอนพิมพ์ dependent: ผิด Rails จะบอกค่าที่ใช้ได้ทั้งหมดในข้อความ error (ดูภารกิจ) — มีอีกสองค่าที่บทนี้ไม่ได้ลอง: :nullify (ลบช่อง post_id ของลูกให้ว่าง — ใช้กับตารางเราไม่ได้ ผมลองแล้วตู้ฟ้อง NotNullViolation เพราะ post_id ตั้ง null: false ไว้) กับ :destroy_async (ทิ้งทีละใบแบบทางที่ ① แต่ทำทีหลังด้วยงานเบื้องหลัง — รอ Day 3)

บล็อกของเราเลือกอะไร: ลบบทความแล้วคอมเมนต์หายตามได้ · และอยากได้ทั้ง callback และการรับประกันของตู้ → ใช้ทางที่ ① คู่กับ ③ · Rails ลบลูกทีละใบก่อน (callback ทำงาน) · ส่วน cascade ในตู้เป็น "ตาข่ายรองรับ" เผื่อมีใครลบข้ามแอป — เป็นหลักเดียวกับประโยคหลักของวันนี้ข้อ ②: กฎใน model ไม่ใช่การรับประกัน ต้องมีกฎที่ตู้คู่กัน

ทำให้แอปของคุณอยู่ในสภาพนี้ก่อนไปหัวข้อถัดไป (โชว์เฉพาะบรรทัดที่เกี่ยว · กฎอื่นจากบทก่อน ๆ คงไว้):

# app/models/post.rb
class Post < ApplicationRecord
  belongs_to :user
  has_many :comments, dependent: :destroy
  has_many :taggings, dependent: :destroy   # ถ้ามีจากบท 115
  has_many :tags, through: :taggings            # ถ้ามีจากบท 115
end

# app/models/comment.rb — ลบบรรทัด after_destroy ที่ใส่ทดลองออก
class Comment < ApplicationRecord
  belongs_to :post
  belongs_to :user
end

migration cascade เก็บไว้ตามเดิม · แล้วสั่ง bin/rails db:reset ให้ได้ข้อมูลครบ 6 บทความ 7 คอมเมนต์

counter_cache — ป้ายตัวเลขบนหน้าแฟ้ม ไม่ต้องเดินไปนับ

หน้ารายการบทความมักโชว์ "มีคอมเมนต์กี่ใบ" ข้างทุกชื่อ · ถ้าเขียนตรง ๆ ทุกบทความจะเดินไปนับที่ลิ้นชัก comments หนึ่งรอบ — นี่คือ N+1 แบบที่บท 114 สอน แต่เป็นรุ่น COUNT:

wongnok-blog(dev):001> Post.all.each { |post| puts "#{post.title}: #{post.comments.size}" }; nil
  Post Load (39.4ms)  SELECT "posts".* FROM "posts" /*application='WongnokBlog'*/
  Comment Count (1.3ms)  SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 1 /*application='WongnokBlog'*/
ต้มยำกุ้งน้ำข้น: 2
  Comment Count (0.9ms)  SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 2 /*application='WongnokBlog'*/
ส้มตำปูปลาร้า: 1
  Comment Count (0.8ms)  SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 3 /*application='WongnokBlog'*/
ข้าวมันไก่ประตูน้ำ: 1
  Comment Count (0.8ms)  SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 4 /*application='WongnokBlog'*/
ก๋วยเตี๋ยวเรืออยุธยา: 0
  Comment Count (0.8ms)  SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 5 /*application='WongnokBlog'*/
ผัดกะเพราหมูสับ: 3
  Comment Count (0.7ms)  SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 6 /*application='WongnokBlog'*/
แกงเขียวหวานไก่: 0
=> nil

• ; nil ท้ายบรรทัด — แค่ให้ console ไม่พิมพ์บทความทั้ง 6 ชิ้นออกมาซ้ำ (บรรทัดนั้นคืนค่า nil แทน)
• หยิบบทความ 1 รอบ + COUNT(*) (นับว่ามีกี่ใบ) อีก 6 รอบ = 7 คำสั่ง · บทความ 50 ชิ้นต่อหน้า = 51 คำสั่ง

counter_cache แก้ด้วยการจดจำนวนไว้บนแฟ้มบทความเลย — เพิ่มช่อง comments_count ในลิ้นชัก posts แล้วให้ Rails บวก/ลบตัวเลขนี้ให้เองทุกครั้งที่มีใบคอมเมนต์เพิ่มหรือหาย · เวลาอยากรู้จำนวน แค่อ่านช่องนี้ ไม่ต้องเดินไปนับ

ขั้นที่ 1 · เพิ่มช่องบนแฟ้ม — สร้าง migration ที่บอกชื่อช่องกับชนิดไปด้วยเลย:

$ bin/rails generate migration AddCommentsCountToPosts comments_count:integer
      invoke  active_record
      create    db/migrate/20261104121224_add_comments_count_to_posts.rb

generator เขียนให้แค่ add_column :posts, :comments_count, :integer · เติม default: 0, null: false เอง (เริ่มที่ 0 และห้ามว่าง — ไม่งั้นบทความใหม่จะมีป้ายว่างเปล่า):

# db/migrate/20261104121224_add_comments_count_to_posts.rb
class AddCommentsCountToPosts < ActiveRecord::Migration[8.1]
  def change
    add_column :posts, :comments_count, :integer, default: 0, null: false
  end
end

$ bin/rails db:migrate
== 20261104121224 AddCommentsCountToPosts: migrating ==========================
-- add_column(:posts, :comments_count, :integer, {default: 0, null: false})
   -> 0.0062s
== 20261104121224 AddCommentsCountToPosts: migrated (0.0062s) =================

ขั้นที่ 2 · บอก Rails ให้ดูแลป้าย — ใส่ที่ฝั่งลูก (belongs_to) เพราะใบคอมเมนต์เป็นคนรู้ว่าตัวเองเพิ่งเกิดหรือเพิ่งหาย:

# app/models/comment.rb
class Comment < ApplicationRecord
  belongs_to :post, counter_cache: true
  belongs_to :user
end

Rails เดาชื่อช่องจากกฎตั้งชื่อ: comments + _count = comments_count · ถ้าตั้งชื่อช่องอื่นต้องบอกชื่อแทน true

post = Post.find_by(title: "ผัดกะเพราหมูสับ")
post.comments.size
post.comments.count

wongnok-blog(dev):002> post.comments.size
=> 0
wongnok-blog(dev):003> post.comments.count
  Comment Count (2.0ms)  SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 5 /*application='WongnokBlog'*/
=> 3

ขั้นที่ 3 · backfill — ให้ตู้นับคอมเมนต์ของทุกบทความแล้วเขียนลงป้ายในคำสั่งเดียว:

wongnok-blog(dev):004> Post.update_all("comments_count = (SELECT COUNT(*) FROM comments WHERE comments.post_id = posts.id)")
  Post Update All (6.1ms)  UPDATE "posts" SET comments_count = (SELECT COUNT(*) FROM comments WHERE comments.post_id = posts.id) /*application='WongnokBlog'*/
=> 6
wongnok-blog(dev):005> Post.pluck(:title, :comments_count)
  Post Pluck (1.9ms)  SELECT "posts"."title", "posts"."comments_count" FROM "posts" /*application='WongnokBlog'*/
=>
[["ต้มยำกุ้งน้ำข้น", 2],
 ["ส้มตำปูปลาร้า", 1],
 ["ข้าวมันไก่ประตูน้ำ", 1],
 ["ก๋วยเตี๋ยวเรืออยุธยา", 0],
 ["ผัดกะเพราหมูสับ", 3],
 ["แกงเขียวหวานไก่", 0]]

• Post.update_all("…") — แก้ทุกแฟ้มในคำสั่งเดียว (ทวนบท 113) · ข้อความในวงเล็บคือ SQL ที่เราเขียนเอง Rails ส่งไปให้ตู้ตามนั้นเลย
• UPDATE "posts" SET comments_count = … — UPDATE … SET = "แก้ช่องนี้ของทุกแฟ้มในลิ้นชัก posts ให้เป็น…" (ไม่มี WHERE = ทุกแผ่น)
• (SELECT COUNT(*) FROM comments WHERE comments.post_id = posts.id) — วงเล็บคือคำถามย่อย: "นับใบคอมเมนต์ที่ post_id ตรงกับเลขที่ของแฟ้มบทความแผ่นที่กำลังแก้อยู่"
• => 6 — แก้ไป 6 แฟ้ม · pluck (บท 113) ยืนยันว่าป้ายตรงกับจำนวนจริงแล้ว

อีกท่าที่เอกสาร Rails แนะนำคือ Post.find_each { |post| Post.reset_counters(post.id, :comments) } = "ไล่ทีละบทความ (find_each จากบท 114) แล้วสั่งนับป้ายใหม่" — ได้ผลเท่ากัน แต่ช้ากว่า (2 คำสั่งต่อบทความ) · ⚠️ ใช้ได้หลังใส่ counter_cache: true แล้วเท่านั้น — สั่งก่อนจะได้ undefined method 'counter_cache_column' for nil (NoMethodError)

backfill ทำครั้งเดียวพอ · ต่อจากนี้ถ้าสั่ง bin/rails db:reset ป้ายจะถูกเองตั้งแต่ต้น เพราะ seeds สร้างคอมเมนต์ผ่าน Rails (p1.comments.create!) ซึ่ง +1 ให้ทุกใบ — ผมลองแล้วได้ 2 · 1 · 1 · 0 · 3 · 0 ตรงกับจำนวนจริง

ผลลัพธ์ — loop เดิมเป๊ะ เหลือคำสั่งเดียว:

wongnok-blog(dev):006> Post.all.each { |post| puts "#{post.title}: #{post.comments.size}" }; nil
  Post Load (2.1ms)  SELECT "posts".* FROM "posts" /*application='WongnokBlog'*/
ต้มยำกุ้งน้ำข้น: 2
ส้มตำปูปลาร้า: 1
ข้าวมันไก่ประตูน้ำ: 1
ก๋วยเตี๋ยวเรืออยุธยา: 0
ผัดกะเพราหมูสับ: 3
แกงเขียวหวานไก่: 0
=> nil

แล้วป้ายอัปเดตเองจริงไหม? ลองเพิ่มแล้วทิ้งคอมเมนต์หนึ่งใบที่บทความแกงเขียวหวาน (ป้ายเป็น 0):

wongnok-blog(dev):007> post = Post.find_by(title: "แกงเขียวหวานไก่")
  … (Post Load — ตัดออก)
wongnok-blog(dev):008> comment = post.comments.create!(user: User.first, body: "รอสูตรอยู่นะ")
  … (User Load — ตัดออก)
  TRANSACTION (1.6ms)  BEGIN /*application='WongnokBlog'*/
  Comment Create (3.9ms)  INSERT INTO "comments" ("body", "post_id", "user_id", "created_at", "updated_at") VALUES ('รอสูตรอยู่นะ', 6, 1, '2026-11-04 12:14:44.371076', '2026-11-04 12:14:44.371076') RETURNING "id" /*application='WongnokBlog'*/
  Post Update All (1.1ms)  UPDATE "posts" SET "comments_count" = COALESCE("posts"."comments_count", 0) + 1 WHERE "posts"."id" = 6 /*application='WongnokBlog'*/
  TRANSACTION (1.6ms)  COMMIT /*application='WongnokBlog'*/
=> #<Comment:0x000000012657e190 id: 8, body: "รอสูตรอยู่นะ", post_id: 6, …>
wongnok-blog(dev):009> post.reload.comments_count
  Post Load (1.1ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" = 6 LIMIT 1 /*application='WongnokBlog'*/
=> 1
wongnok-blog(dev):010> comment.destroy
  TRANSACTION (2.2ms)  BEGIN /*application='WongnokBlog'*/
  Comment Destroy (4.3ms)  DELETE FROM "comments" WHERE "comments"."id" = 8 /*application='WongnokBlog'*/
  Post Update All (2.0ms)  UPDATE "posts" SET "comments_count" = COALESCE("posts"."comments_count", 0) - 1 WHERE "posts"."id" = 6 /*application='WongnokBlog'*/
  TRANSACTION (2.2ms)  COMMIT /*application='WongnokBlog'*/
=> #<Comment:0x000000012657e190 id: 8, …>
wongnok-blog(dev):011> post.reload.comments_count
  Post Load (2.6ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" = 6 LIMIT 1 /*application='WongnokBlog'*/
=> 0

• INSERT INTO "comments" (…) VALUES (…) RETURNING "id" — INSERT = "เพิ่มแฟ้มใหม่ลงลิ้นชัก comments โดยกรอกช่องในวงเล็บแรกด้วยค่าในวงเล็บหลัง แล้วบอกเลขที่ (id) ที่ได้กลับมา" (แบบเดียวกับบท 107)
• UPDATE "posts" SET "comments_count" = COALESCE("posts"."comments_count", 0) + 1 WHERE "posts"."id" = 6 — บรรทัดที่ counter_cache เพิ่มให้: "แก้ป้ายของบทความเลขที่ 6 เป็น เลขเดิม +1" · COALESCE(…, 0) = "ถ้าช่องว่าง ให้ถือเป็น 0" · ตอนทิ้งก็ −1 · อยู่ใน transaction เดียวกับ INSERT/DELETE ใบคอมเมนต์
• post.reload — โหลดแฟ้มบทความจากตู้ใหม่ (Post Load) เพราะตัวแปร post ในมือยังเป็นค่าเก่า
• เลขที่ใบคอมเมนต์ (8) ของคุณอาจต่าง ถ้าเคยสร้างคอมเมนต์เพิ่มไว้

เทียบกับ Go: GORM ไม่มีป้ายอัตโนมัติ — ต้องเพิ่ม field CommentsCount ใน struct แล้วเขียน UPDATE posts SET comments_count = comments_count + 1 เองทุกที่ที่สร้างคอมเมนต์ (และอย่าลืมใส่ใน transaction เดียวกัน) · Rails เขียนให้ทุกที่จากบรรทัดเดียว

touch และ inverse_of — ของเล็กอีกสองชิ้น

touch: true = "ทุกครั้งที่ใบคอมเมนต์ถูกเก็บหรือทิ้ง ให้แก้เวลา updated_at (แก้ไขล่าสุดเมื่อ) ของบทความแม่เป็นเวลาปัจจุบันด้วย" · มีไว้ให้ระบบรู้ว่า "บทความนี้มีอะไรเปลี่ยน" แม้ตัวบทความเองไม่ได้ถูกแก้ — สำคัญมากตอนทำ cache (เก็บหน้าเว็บที่ทำเสร็จแล้วไว้ใช้ซ้ำ ไม่ต้องทำใหม่ทุกครั้ง — Day 3)

# app/models/comment.rb
  belongs_to :post, counter_cache: true, touch: true

wongnok-blog(dev):001> post = Post.find_by(title: "ส้มตำปูปลาร้า")
  … (Post Load — ตัดออก)
wongnok-blog(dev):002> post.updated_at
=> 2026-11-04 12:13:58.622813000 UTC +00:00
wongnok-blog(dev):003> post.comments.create!(user: User.last, body: "ใส่ปูดองด้วยไหม")
  … (User Load · BEGIN · INSERT ใบคอมเมนต์ — ตัดออก)
  Post Update All (1.0ms)  UPDATE "posts" SET "comments_count" = COALESCE("posts"."comments_count", 0) + 1, "updated_at" = '2026-11-04 12:15:14.736287' WHERE "posts"."id" = 2 /*application='WongnokBlog'*/
  TRANSACTION (1.4ms)  COMMIT /*application='WongnokBlog'*/
=> #<Comment:0x000000012790bfc8 id: 9, body: "ใส่ปูดองด้วยไหม", post_id: 2, …>
wongnok-blog(dev):004> post.reload.updated_at
  Post Load (3.1ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" = 2 LIMIT 1 /*application='WongnokBlog'*/
=> 2026-11-04 12:15:14.736287000 UTC +00:00

• เวลา updated_at ของบทความเปลี่ยนจาก 12:13:58 เป็น 12:15:14 — ทั้งที่เราไม่ได้แตะตัวบทความเลย (ของคุณจะเป็นวันเวลาตอนที่ลอง · UTC = เวลามาตรฐานโลก ช้ากว่าไทย 7 ชั่วโมง)
• Rails ฉลาดพอรวมสองงานไว้ใน UPDATE เดียว: +1 ที่ป้าย และประทับเวลาใหม่

เทียบกับ Go: GORM ไม่มีตัวเลือกแบบนี้ — ถ้าอยากให้เวลาของบทความเปลี่ยนตามคอมเมนต์ ต้องสั่งแก้ UpdatedAt ของบทความเองทุกที่ที่สร้าง แก้ หรือลบคอมเมนต์ · Rails ทำให้ทุกที่จากคำว่า touch: true คำเดียว

inverse_of — แค่รู้จักไว้ · มันบอก Rails ว่า has_many :comments ฝั่ง Post กับ belongs_to :post ฝั่ง Comment คือความสัมพันธ์เส้นเดียวกันมองจากสองฝั่ง · ประโยชน์คือ ถ้าเราหยิบคอมเมนต์ผ่านบทความ แล้วถามกลับว่า "ใบนี้เป็นของบทความไหน" Rails ตอบด้วย object บทความตัวเดิมในมือ ไม่เดินไปตู้อีกรอบ · ส่วนใหญ่ Rails เดาเองได้จากชื่อ — ผมลองแล้ว ไม่ต้องเขียนอะไรเพิ่ม:

wongnok-blog(dev):001> post = Post.find_by(title: "ต้มยำกุ้งน้ำข้น")
  … (Post Load — ตัดออก)
wongnok-blog(dev):002> comment = post.comments.first
  Comment Load (2.5ms)  SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = 1 ORDER BY "comments"."id" ASC LIMIT 1 /*application='WongnokBlog'*/
=> #<Comment … (ตัดออก)
wongnok-blog(dev):003> comment.post.equal?(post)
=> true

• post.comments.first — หยิบใบคอมเมนต์ใบแรกของต้มยำกุ้ง (ORDER BY … ASC LIMIT 1 = เรียงเลขที่จากน้อยไปมาก แล้วเอาใบแรก)
• comment.post.equal?(post) — equal? = "เป็น object ตัวเดียวกันเป๊ะไหม" (ไม่ใช่แค่ค่าเท่ากัน) → true และไม่มี SQL เลยตอนเรียก comment.post

เทียบกับ Go: ใน GORM field Post ใน struct Comment เป็นก้อนข้อมูลอีกก้อนที่ต้องสั่งโหลด (Preload) เอง ไม่ได้ชี้กลับไปหาตัวแปร post ที่ถืออยู่อัตโนมัติ · Rails ทำให้เองเมื่อชื่อตรงกฎ

ภารกิจ: ห้ามลบผู้ใช้ที่ยังมีผลงานอยู่

ตอนนี้บทความจัดการเรียบร้อยแล้ว · แต่ผู้ใช้ (User) ยังไม่มีใครตัดสินว่า "ลบผู้ใช้แล้วบทความกับคอมเมนต์ของเขาไปไหน" · ธุรกิจตอบมาแล้ว: "ห้ามลบผู้ใช้ที่ยังมีบทความหรือคอมเมนต์ — ให้แจ้งว่าลบไม่ได้ ไม่ใช่หน้าแดง"

# app/models/user.rb (โชว์เฉพาะสองบรรทัดที่แก้ · validates และ has_many อื่นจากบท 110–115 คงไว้)
class User < ApplicationRecord
  has_many :posts, dependent: :restrict_with_error
  has_many :comments, dependent: :restrict_with_error
end

wongnok-blog(dev):001> mana = User.find_by(name: "มานะ")
  User Load (1.9ms)  SELECT "users".* FROM "users" WHERE "users"."name" = 'มานะ' LIMIT 1 /*application='WongnokBlog'*/
=> #<User:0x000000012374cc90 id: 3, name: "มานะ", email: "[FILTERED]", …>
wongnok-blog(dev):002> mana.destroy
  TRANSACTION (1.2ms)  BEGIN /*application='WongnokBlog'*/
  User Destroy (3.7ms)  DELETE FROM "users" WHERE "users"."id" = 3 /*application='WongnokBlog'*/
  TRANSACTION (0.4ms)  ROLLBACK /*application='WongnokBlog'*/
(wongnok-blog):2:in '<main>': PG::ForeignKeyViolation: ERROR:  update or delete on table "users" violates foreign key constraint "fk_rails_03de2dc08c" on table "comments" (ActiveRecord::InvalidForeignKey)
DETAIL:  Key (id)=(3) is still referenced from table "comments".
…

wongnok-blog(dev):003> reload!
Reloading...
=> nil
wongnok-blog(dev):004> mana = User.find_by(name: "มานะ")
  User Load (0.9ms)  SELECT "users".* FROM "users" WHERE "users"."name" = 'มานะ' LIMIT 1 /*application='WongnokBlog'*/
=> #<User:0x00000001224d23d0 id: 3, name: "มานะ", email: "[FILTERED]", …>
wongnok-blog(dev):005> mana.destroy
  TRANSACTION (1.3ms)  BEGIN /*application='WongnokBlog'*/
  Post Exists? (1.4ms)  SELECT 1 AS one FROM "posts" WHERE "posts"."user_id" = 3 LIMIT 1 /*application='WongnokBlog'*/
  TRANSACTION (0.9ms)  ROLLBACK /*application='WongnokBlog'*/
=> false
wongnok-blog(dev):006> mana.errors.full_messages
=> ["Cannot delete record because dependent posts exist"]
wongnok-blog(dev):007> newbie = User.create!(name: "ทดลอง", email: "test@example.com")
  TRANSACTION (2.1ms)  BEGIN /*application='WongnokBlog'*/
  User Create (4.1ms)  INSERT INTO "users" ("name", "email", "created_at", "updated_at") VALUES ('ทดลอง', 'test@example.com', '2026-11-04 12:24:36.357292', '2026-11-04 12:24:36.357292') RETURNING "id" /*application='WongnokBlog'*/
  TRANSACTION (1.8ms)  COMMIT /*application='WongnokBlog'*/
=> #<User:0x000000011fd0a3c0 id: 4, name: "ทดลอง", email: "[FILTERED]", …>
wongnok-blog(dev):008> newbie.destroy
  TRANSACTION (2.1ms)  BEGIN /*application='WongnokBlog'*/
  Post Exists? (3.9ms)  SELECT 1 AS one FROM "posts" WHERE "posts"."user_id" = 4 LIMIT 1 /*application='WongnokBlog'*/
  Comment Exists? (1.0ms)  SELECT 1 AS one FROM "comments" WHERE "comments"."user_id" = 4 LIMIT 1 /*application='WongnokBlog'*/
  User Destroy (1.3ms)  DELETE FROM "users" WHERE "users"."id" = 4 /*application='WongnokBlog'*/
  TRANSACTION (1.6ms)  COMMIT /*application='WongnokBlog'*/
=> #<User:0x000000011fd0a3c0 id: 4, name: "ทดลอง", email: "[FILTERED]", …>
wongnok-blog(dev):009> User.count
  User Count (2.5ms)  SELECT COUNT(*) FROM "users" /*application='WongnokBlog'*/
=> 3

Quiz

ถามกลับได้เลย

ถ้าตารางของคุณมีลูกหลายชั้น (บทความ → คอมเมนต์ → ไลก์) แล้วไม่แน่ใจว่าแต่ละชั้นควรใช้ dependent แบบไหน — ส่งให้เพื่อน senior หรือ AI สามอย่าง: db/schema.rb · model ทุกตัวที่เกี่ยว · และคำตอบของธุรกิจว่า "ลบแม่แล้วลูกต้องเป็นยังไง" · อย่างสุดท้ายสำคัญที่สุด ไม่มีมันใครก็ตอบแทนไม่ได้

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

อ้างอิง

• Rails Guides — Active Record Associations · :dependent — อ่านหัวข้อ 8.1.2 :dependent รายการค่าทั้งหมดพร้อมคำอธิบายสั้น ๆ ว่าแต่ละค่าเรียก callback หรือไม่
• Rails Guides — Active Record Associations · Counter Cache — อ่านหัวข้อ 8.3 Counter Cache (ตัวอย่าง Book/Author แบบเดียวกับ Post/Comment) แล้วต่อด้วย 8.1.5 :touch และ 8.1.7 :inverse_of
• Rails API — reset_counters — อ่านย่อหน้าแรก ที่บอกว่าใช้ตอนเพิ่ม counter cache ใหม่ หรือตอนเลขเพี้ยนเพราะมีคนแก้ด้วย SQL ตรง ๆ
• Rails API — add_foreign_key — อ่านรายการ options ตรง :on_delete (ค่าที่ใช้ได้: :nullify · :cascade · :restrict) · คู่กับ remove_foreign_key
• PostgreSQL 17 — 5.5.5 Foreign Keys — อ่านช่วงที่อธิบาย ON DELETE CASCADE กับ RESTRICT ด้วยตัวอย่าง orders/products — นี่คือกฎของตู้ที่ทางที่ ③ ใช้
• GORM — Delete Associations และ GORM — Foreign Key Constraint — ฝั่ง Go ที่เทียบในบทนี้: Select(...).Delete กับ tag constraint:OnDelete