railsでアプリを作っています。DBのnull:falseとモデルでのvalidatesでのpresence trueの違いを教えてください

Question

railsでマイグレーションファイルのカラムに

null:false
をつけるのと、

モデルで
validate :name presence: true
をつけるのは役割が被っている気がするのですが、厳密には違うのでしょうか？

また、併記する必要があるのか？
どっちかでいいのか？
曖昧な認識でしかないので詳しい方教えていただけるとありがたいです。

Answer 1

モデルのバリデーションは、想定しうる入力の間違いをチェックするものですが、
自分が想定していなかったものはすり抜けてしまいます。
最後の砦、保険となるのが、DB側の制約です。

モデルを修正していくうちに、validate :name presence: true を
うっかり削除してしまうかもしれないし、
新規に作ったモデルで付け忘れる可能性もあります。

重複しているように見えても役割は別物なので、モデルのバリデーションもDB側の制約もきちんと設定すべきです。

Answer 2

railsの動作ですが

migrationファイルに
:name#, :null => false
と記載した場合にモデルのインスタンスをsaveすると
ActiveRecord::StatementInvalid: PG::NotNullViolation: ERROR: null value in column "name" violates not-null constraint
というエラーがraiseされます。（postgresの場合）

モデルに
validates :name, presence: true
と記載した場合はrails側でのチェックが走りますので、
モデルのインスタンスに対して #save、 #valid? などを実行した場合falseが返り、インスタンスのerrorsにエラーがセットされます。

上の結果から

• データベースにチェックしてもらうよりも事前にチェックしたほうが安全
• 同じモデルに対して他のvalidationも併用する場合にmigrationファイルに定義すると、チェックするタイミングがずれる

ため、modelで定義するほうがいいかと思います。

また、通常（scaffoldなどで）作成したcontrollerでは

def create
  model = Model.new(model_params)

  if model.save
    # 成功時の処理
  else
    # unprocessable entity（422）などのvalidationエラーの処理
  end
end

のようになるので、railsではmodelでvalidationを定義することを前提にしてそうです。

Comments

[dongw]

コメントありがとうございます！
modelにvalidationをかけたほうがfalseが返ってくるのでフラッシュメッセージなどにも利用でき、いろいろと再利用できますよね

ただ、DBにnull不許可とモデルにバリデーションをかけたほうがより安全（二重だから）
DBを直接いじる機会にnullがまちがって入ってしまうと危険だからDBにもnull不許可する、ということも聞いたのですが、この事についてはどう思いますか？

[satoshih]

> DBを直接いじる機会
そうですね
そういう機会があるのであれば、おっしゃる通り２重に（applicationとDB両方で）かけておくほうが安全だとおもいます
（そんな機会が無いことを祈っときます。

[dongw]

ありがとうございます。
ベストアンサーにいたしました！