本当は怖い Rails の `build_xxx` / The Hard Facts of `build_xxx` of Rails

Transcript

1. 本当は怖い Rails の build_xxx @ giftee tech bash #2 (2019‑07‑30) kazama (@megane42) Solution dev. GCP
2. 概要 Rails の build_xxx 系のメソッドが怖かったという話をします
3. 今日の登場人物（モデル） User Blog user has_one blog
4. お題 ある user の持ち物としての blog インスタンスを作りたい
5. 方法 create_xxx インスタンスを作って DB に即保存 user.create_blog(title: "foo", ...) build_xxx インスタンスは作るけど DB に保存はしない 今日の主役 user.build_blog(title: "foo", ...)
6. 疑問 has_one だけど何度も繰り返したらどうなるの？
7. create の場合 まず新しい blog レコードを保存 次に古い blog レコードの外部キー (user_id) を null にする dependent: :destroy のときはここが DELETE になる 結果的に子レコードは 1 つに保たれるので、まあわかる # 2 回目の user.create_blog を実行したときの SQL begin transaction INSERT INTO "blogs" ("user_id", "created_at", "updated_at" commit transaction begin transaction UPDATE "blogs" SET "user_id" = ?, "updated_at" = ? WHERE commit transaction
8. build の場合 # 1 回目 blog = user.build_blog blog.save # 2 回目 blog = user.build_blog さて何が起きるでしょう？
10. 結果 まさかの 更新系 が走る dependent: :destroy の場合は DELETE が走る！ このあと結局 blog.save をしなかった場合 or 失敗した場合、当 然旧レコードは更新されっぱなしのまま build_xxx は DB を更新しない、という直感に反している # 2 回目の blog = user.build_blog を実行したときの SQL begin transaction UPDATE "blogs" SET "user_id" = ?, "updated_at" = ? WHERE commit transaction
11. 対策 new を使う build_xxx まで含めてトランザクションを張る build_xxx が更新系を実行しうる、という認識を持っておく transaction do blog = user.build_blog blog.some_operation blog.save end
12. 余談 : ドキュメントにはどう書いてある？ Account#build_beneficiary (similar to Beneficiary.new(account_id: id) ) シミラートゥー（イコールとは言ってない） https://api.rubyonrails.org/classes/ActiveRecord/Associations/Cla ssMethods.html#method‑i‑has_one
13. 余談 : create_xxx も怖くね？ なぜか トランザクションが分かれている INSERT 後の UPDATE or DELETE に失敗するとゴミレコードが残る 例えば belongs_to: に optional: true を付け忘れると UPDATE に失敗する これもトランザクション張った方がいいのかも？ # 2 回目の user.create_blog を実行したときの SQL （再掲） begin transaction INSERT INTO "blogs" ("user_id", "created_at", "updated_at" commit transaction begin transaction UPDATE "blogs" SET "user_id" = ?, "updated_at" = ? WHERE commit transaction
14. まとめ build_xxx は 更新系 を発行しうる create_xxx も怖かった