1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

【Rails】データが更新できない時は、バリデーションを確認

Posted at

1. はじめに

アプリを作成している際に、Userテーブルに追加したカラムのデータが更新できずに困りました。
しかも、エラー文が出ないので何が原因なのかがなかなか分からずあたふたしていました。
最終的には原因を見つけられたのですが、解決に至るまでに思いの外、多くの時間を費やしてしまいました。
同じような現象で、時間を費やしてしまう人が少しでも減るように、ここに備忘録を残します。

#2. きっかけ
そもそもエラー文が出ていないのに、なぜデータが更新されていないことに気づいたかというと、
更新されたはずのデータを元に検索機能を実装しようとしたときに、
登録したはずのデータで検索結果が返ってくるはずが、なぜかデフォルト値で返ってきたので、
「あれ?おかしいな」と思ったのが始まりでした。

rails cでテーブルの中身を確認したらやっぱり更新されていない...。
コンソールを見ると、データが更新される段階でRollbackされていました。

コンソール
  ↳ app/controllers/users_controller.rb:11
   (0.2ms)  ROLLBACK

#3. 原因
結論から言うと、パスワードにかけていたバリデーションが原因でした。
ユーザーのデータを更新する際に、パスワードの入力が必要である設定になっていたのですが、
パスワードなしに、@user.updateをしようとしていたので、結果的にデータが更新されなかったようです。

app/
def show
  @user.update (
    marriage: @post.marriage,
    childcare: @post.childcare,
   )
end

と言うことで、バリデーションの設定を変更します。
ユーザー情報更新の場合、パスワードのバリデーションを外すように設定するのは、

user.rb(変更前)
validates :password, format: { with: password_format }, length: { in: 8..32 }

ここにon: :createを追加します。
こうすることでユーザー情報を登録する際のみにパスワードのバリデーションがかかります。

user.rb(変更後)
validates :password, format: { with: password_format }, length: { in: 8..32 }, on: :create

ユーザー情報更新の際に、パスワードのバリデーションがかからなくなったので、無事データが登録されるようになりました。

#4. 最後に
原因は意外と単純でした。自分でバリデーションをかけておきながら忘れる始末。
灯台下暗しってやつですね...。今後は気をつけようと反省した次第です。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?