Ruby on RailsのActiveRecord検証を理解する

データは素晴らしいことですが、間違ったデータは非常に悪いことがあります。 幸いなことに、Ruby on Railsプログラマであれば、ActiveRecord検証ヘルパーの素晴らしいAPIを自由に使用できます。

このガイドは、特定のRuby on Railsアプリケーションにおける一般的であまり一般的ではないActiveRecord検証の探索です。 あなたのデータベースを幸せに保つのを助けるためにそれを使用してください！

なぜ検証を使用するのですか？有効なデータのみがデータベースに保存されるようにします。

クライアント側の検証の上に、モデルレベルの検証は、Ruby on Railsアプリケーション内の任意およびすべてのフォームフィールドのための余分なセキュリテ

さまざまなレベルで検証を提供できますが、すべてに長所と短所があります。

• データベース制約-データベースレベルの一意の制約では、必要に応じて重複するフィールドや列を許可しません。 これは、単に一意性よりもはるかに深く行くことができます。 つまり、デフォルト値、非nil制約、範囲などです。..
• クライアント側の検証-これらは視覚的に有用であり、より良いユーザーエクスペリエンスを提供しますが、多くの場合、より信頼性 私はほとんどの場合、このアプローチを使用してバックアップ計画を提供します。
• モデルレベル（Rails）-私たちが今話していること！
• コントローラレベル（Rails）-使用するのは魅力的ですが、テストと保守がより困難です。 コントローラをできるだけ軽く保つことは、慣習/ベストプラクティスです。

検証はいつ実際に行われますか？

ruby on railsのドキュメントから直接:

アクティブレコードオブジェクトには、データベース内の行に対応するものとそうでないものがあります。 たとえば、newsavenew_record?new_record?rails console

$ rails console>> article = Article.new(title: "My Article")=> #<Article id:nil title: "My Article", created_at: nil, updated_at: nil>>> article.new_record?=> true>> article.save=> true>> article.new_record?=> false

実際にsaveSQL文を作成します。 その結果、検証は通常、データベースにデータを完全に送信する前に実行されます。 次のメソッドは、使用時に検証を呼び出します。

• create
• create!
• save
• save!
• save!
• save!
• create
• create
• update
• update!

bangバージョン（例：save!saveupdatefalsecreateちょうどオブジェクトを返します。

検証をスキップするメソッド

次のいずれかを使用すると、検証が完全にスキップされます。 貴重なデータには注意して使用してください！

• decrement!
• decrement_counter
• increment!
• increment_counter
• toggle!
• touch
• update_all
• update_attribute
• update_column
• update_columns
• update_counters

Validation helpers

What I love about Ruby on Rails is the bundled goodness you get for doing pretty hard things. 検証ヘルパーは、新しいアプリを野生で展開するときに暖かく居心地の良い気分にさせるものの一つです。 これにより、クライアント側から収集する可能性のある広範なデータに対して多くのサポートが提供されます。各ヘルパーは:on:messageerrorsコレクションに追加するメッセージを定義します（これらを使用して、ユーザーが何を変更/変更するかを知っているように、ビュー内に何が間違っているのかを注入するのに役立ちます）。 以下は私の最も使用されているいくつかです。

より多くのユースケースについては、active record validationsに関するガイドを参照してください。

確認

二つのテキストフィールドが同じエントリを持つ必要があるときに検証するのに便利です。 たとえば、電子メールの確認を考えてみてください。ここでの1つの問題は、この検証がモデルでもpresenceオプションがtrueに設定されている場合にのみ実行されることです。

class User < ApplicationRecord validates :email, confirmation: trueend

これで、ビューで2つのフィールドを持つことができます。

<%= text_field :user, :email %><%= text_field :user, :email_confirmation %>

したがって、Userモデルが更新されます。

class User < ApplicationRecord validates :email, confirmation: true validates :email_confirmation, presence: true end

除外

単語を予約する必要がある場合や、特定のエントリが一意であることを確認する必要がある場合は、exclusion:messageinclusionを使用することもできます。 詳細については、docsを参照してください！

Format

書式設定文字列は、アプリにとって理想的な場合があります。 検証内で正規表現を使用して、後にしているものを変更することができます。p>

class Plan < ApplicationRecord validates :plan_type, format: { with: /\A+\z/, message: "Plans can only inlude letters"}end

長さ

私は与えられたフィールドの文字長に制約を置くためにこれを常に使用しています。p>

class User < ApplicationRecord validates :name, length: { minimum: 5 } # sets a minimum validates :bio, length: { maximum: 500 } # sets a maximum validates :handle, length: { in: 5..16 } # provide a rangeend

ここでも:messageでメッセージをパーソナライズして自由に感じてください。 以下はすべて、メッセージをカスタマイズするためにフックすることができます。/p>

• wrong_length
• too_long
• too_short

例

class User < ApplicationRecord validates :bio, length: { maximum: 800, too_long: "%{count} characters is the maximum." }end

プレゼンス

プレゼンス

プレゼンス

プレゼンス

プレゼンス

プレゼンス

プレゼンス

プレゼンス

プレゼンス

プレゼンス

プレゼンス

/h3>

これはおそらく私のツールバッグの中で最も広く使用されているヘルパーです。 プレゼンスは、フィールドが空でないことを確認します。 また、関連付けがモデルに存在することをテストすることができます

class Article < ApplicationRecord belongs_to :user validates :user, presence: true # looks for a user_id field on the articleend

反対のモデルでは、inverse_of

class User < ApplicationRecord has_many :articles, inverse_of: :userend

一意性

アプリに一意のユーザー名が必要な場合がありますか？ 一意性はそれに役立ちます。これは実際にUseruniqueness

さらに進み、uniquenessuniquenessuniquenessuniquenessuniquenessuniquenessuniquenessuniqueness

scope。

class User < ApplicationRecord validates :plan, uniqueness: { scope: :year, message: "can only update one per year"}end

条件付き検証

場合によっては、指定された条件内でのみ検証する必要があります。 次のようなアプローチを使用して条件演算を実行できます。p>

class Purchase < ApplicationRecord validates :card_number, presence: true, if: :paid_with_card? def paid_with_card? payment_type == "card" endend

複数の条件をグループ化する必要がありますか？ あなたはそれを行うことができます

class User < ApplicationRecord with_options if: :is_admin? do |admin| admin.validates :location, length: { minimum: 10 } admin.validates :job_title, presence: true endend

カスタムメソッド

ヘルパーが十分ではなく、よりカスタムなものが必要な場合があ 自分でロールするいくつかの検証を行う独自のメソッドを作成することができます。ここでは、検証を初期化する場所を決定できる:on:createerrors:messageがありません。 エラーについての詳細をお読みください。うまくいけば、検証はあなたのアプリをより制約のあるものにするためのいくつかのアイデアを開いています（良い方法で）。 Ruby on Railsとそのすべてのファセットを使用すると、安全なデータが選択した任意のデータベースに入ることができます。 CSRFトークンからデータベースレベルの検証まで、アプリを強化するための無限の方法があります。

恥知らずのプラグ！あなたはこの記事が好きなら、私はYouTubeで、ここに私のブログでより多くのビデオを持っています。

あなたの受信トレイにこのようなより多くのコンテンツをしたいですか？ 私の時事通信を予約購読し、それを自動的に得なさい。

私のコースをチェックしてください

☝Ruby on Railsを一から学びたいですか？ チェックして次のコースと呼ばれこんにちはします。