Editing article

Title

Summary

Content

Having spent a few too many years working in desktop support, if there’s one thing I can tell you about the users of your software, it’s that they’re going to use it incorrectly.<figure><img alt="" src="https://cdn-images-1.medium.com/max/258/1*N_Dj3E0_B5DFW7C0n7GeEQ.gif" /><figcaption>You probably won’t break the internet if you do this, but are you willing to take that risk?</figcaption></figure>As software engineers, part of our job is to make sure that the software we write doesn’t break when used in unexpected ways and, when users inevitably do something wrong, to do our best to communicate where they went wrong and how to correct it, otherwise, before long our software probably won’t have any users (or at the very least, we won’t have any happy users). Depending on the application, you might be able to limit the things your users can do such that there’s no way they can make your application do anything you don’t want them to do, but in most cases this just isn’t realistic.<h3>Enter data validation</h3>Building simple CLI apps at Flatiron recently, I’ve figured out some techniques for dealing with unexpected inputs and, as my applications have become more complex, I imagined the work involved in accounting for user error would increase at the same rate…but my code is on Rails now, and Rails does magic tricks.<figure><img alt="" src="https://cdn-images-1.medium.com/max/500/1*scEhON2k13kP2FbXBo2NsQ.gif" /></figure>Thankfully, the illusionists/engineers who built Rails have provided us with ways to take a lot of the work out of making sure our users are putting the right information in the right place, and in the right format, in the form of <a href="http://guides.rubyonrails.org/active_record_validations.html#validation-helpers">validation helpers</a>. Active Record’s validation helpers cover a lot of cases we might find ourselves needing to account for.Need to make sure the username field is filled out on the form for a new account? “Presence” is about as basic as validation gets — is there something here?<pre>class User &lt; ApplicationRecord validates :name, presence: true end</pre><pre>Person.create(name: &quot;Beef Supreme&quot;).valid? # =&gt; true Person.create(name: nil).valid? # =&gt; false</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/600/1*_woZtXKXcamwDHTeVgg8RA.jpeg" /></figure>If so, great, Beef Supreme can create his account. If not, Rails, along with a little effort on our part, can tell Mr. Supreme that he forgot to enter his name. But, as anyone who knows Beef Supreme is aware, he’s not the sharpest, so what if he already has an account?<pre>class Account &lt; ApplicationRecord validates :email, uniqueness: true end</pre>“uniqueness: true” will check to see if Beef has already registered his email address and, if so, generates an error message:<pre>beef.supreme@brawndo.com has already been taken</pre>I won’t go into all of the helpers here, but I do want to take a look at some of the ways you can extend their functionality beyond their basic syntax. Let’s say we have a simple Beer model, and our schema looks like this:<pre>create_table &quot;beers&quot;, force: :cascade do |t| t.string &quot;name&quot; t.string &quot;brewery&quot; t.string &quot;style&quot; t.float &quot;abv&quot; t.text &quot;description&quot; t.integer &quot;vintage&quot; end</pre>Validating that all of these fields have been filled out (to say nothing of other validations we might need to do) in our new beer form would get repetitious, and doing it like this doesn’t look very DRY:<pre>class Beer &lt; ActiveRecord::Base validates :name, presence: true validates :brewery, presence: true validates :style, presence: true validates :abv, presence: true end</pre>But this accomplishes the same thing:<pre>validates :name, :brewery, :style, :abv, presence: true</pre>If we want to check to see if a beer is already in our database, we can use “uniqueness”, but some brewers just name their beers after the style, and we might want to keep track of different vintages of the same beer separately.<pre>validates :name, uniqueness: { scope: [:brewery, :vintage] }</pre>Passing the “scope” option to our uniqueness validation allows us to check for a unique combination of properties, here ensuring that the same beer name, by a different brewery or of a different vintage, will be treated as a unique beer.In other cases, the permitted values for one property may depend on the value of another. Here we can use conditional validations, for example, making sure the ABV of a beer is within the typical range, unless it’s a barleywine, in which case the sky’s the limit:<pre>validates :abv, inclusion: { in: 0...30 }, unless: Proc.new { |b| b.style == &quot;barleywine&quot; }</pre><h3>Custom Validations</h3>As you can see, Rails’ validation helpers are pretty versatile, and in many cases can provide everything we need to make sure we’re only accepting properly validated data, but Rails’ magic can’t account for every situation.<figure><img alt="" src="https://cdn-images-1.medium.com/max/658/1*9eCJB24Xj96LeIIuNI76NQ.png" /></figure>Custom validations are classes that inherit from ActiveModel::Validator (you can also write custom methods in your models, and call them using “validate :method_name”), allowing you to build whatever functionality you need into your checks, although Cueball’s issue illustrated above might be beyond help.More on Active Record validations:<a href="https://www.google.com/url?sa=t&amp;rct=j&amp;q=&amp;esrc=s&amp;source=web&amp;cd=1&amp;cad=rja&amp;uact=8&amp;ved=0ahUKEwjSsZnSit3YAhWSUd8KHf4mDKkQFggpMAA&amp;url=http%3A%2F%2Fguides.rubyonrails.org%2Factive_record_validations.html&amp;usg=AOvVaw0r4zKycKCtlitzQA8hIZWm">Rails Guides — Validations</a><a href="https://hackernoon.com/performing-custom-validations-in-rails-an-example-9a373e807144">Performing Custom Validations in Rails — an Example</a><a href="https://robots.thoughtbot.com/the-perils-of-uniqueness-validations">The Perils of Uniqueness Validations</a><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=890519b94fe7" width="1" height="1" alt="">

Author

Link

Published date

Image url

Feed url

Guid

Hidden blurb

--- !ruby/object:Feedjira::Parser::RSSEntry
published: 2018-01-16 05:18:12.000000000 Z
carlessian_info:
 news_filer_version: 2
 newspaper: Kevin Randles on Medium
 macro_region: Technology
entry_id: !ruby/object:Feedjira::Parser::GloballyUniqueIdentifier
 is_perma_link: 'false'
 guid: https://medium.com/p/890519b94fe7
title: Active Record Validations
categories:
- ruby-on-rails
- flatiron-school
content: 'Having spent a few too many years working in desktop support, if there’s
 one thing I can tell you about the users of your software, it’s that they’re going
 to use it incorrectly.<figure><img alt="" src="https://cdn-images-1.medium.com/max/258/1*N_Dj3E0_B5DFW7C0n7GeEQ.gif"
 /><figcaption>You probably won’t break the internet if you do this,
 but are you willing to take that risk?</figcaption></figure>As software engineers,
 part of our job is to make sure that the software we write doesn’t break when used
 in unexpected ways and, when users inevitably do something wrong, to do our best
 to communicate where they went wrong and how to correct it, otherwise, before long
 our software probably won’t have any users (or at the very least, we won’t have
 any happy users). Depending on the application, you might be able to limit the things
 your users can do such that there’s no way they can make your application do anything
 you don’t want them to do, but in most cases this just isn’t realistic.<h3>Enter
 data validation</h3>Building simple CLI apps at Flatiron recently, I’ve figured
 out some techniques for dealing with unexpected inputs and, as my applications have
 become more complex, I imagined the work involved in accounting for user error would
 increase at the same rate…but my code is on Rails now, and Rails does magic tricks.<figure><img
 alt="" src="https://cdn-images-1.medium.com/max/500/1*scEhON2k13kP2FbXBo2NsQ.gif"
 /></figure>Thankfully, the illusionists/engineers who built Rails have provided
 us with ways to take a lot of the work out of making sure our users are putting
 the right information in the right place, and in the right format, in the form of
 <a href="http://guides.rubyonrails.org/active_record_validations.html#validation-helpers">validation
 helpers</a>. Active Record’s validation helpers cover a lot of cases we might find
 ourselves needing to account for.Need to make sure the username field is
 filled out on the form for a new account? “Presence” is about as basic as validation
 gets — is there something here?<pre>class User &lt; ApplicationRecord validates
 :name, presence: true end</pre><pre>Person.create(name: &quot;Beef
 Supreme&quot;).valid? # =&gt; true Person.create(name: nil).valid? # =&gt;
 false</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/600/1*_woZtXKXcamwDHTeVgg8RA.jpeg"
 /></figure>If so, great, Beef Supreme can create his account. If not, Rails,
 along with a little effort on our part, can tell Mr. Supreme that he forgot to enter
 his name. But, as anyone who knows Beef Supreme is aware, he’s not the sharpest,
 so what if he already has an account?<pre>class Account &lt; ApplicationRecord validates
 :email, uniqueness: true end</pre>“uniqueness: true” will
 check to see if Beef has already registered his email address and, if so, generates
 an error message:<pre>beef.supreme@brawndo.com has already been taken</pre>I
 won’t go into all of the helpers here, but I do want to take a look at some of the
 ways you can extend their functionality beyond their basic syntax. Let’s say we
 have a simple Beer model, and our schema looks like this:<pre>create_table &quot;beers&quot;,
 force: :cascade do |t| t.string &quot;name&quot; t.string &quot;brewery&quot; t.string &quot;style&quot; t.float &quot;abv&quot; t.text &quot;description&quot; t.integer &quot;vintage&quot; end</pre>Validating
 that all of these fields have been filled out (to say nothing of other validations
 we might need to do) in our new beer form would get repetitious, and doing it like
 this doesn’t look very DRY:<pre>class Beer &lt; ActiveRecord::Base validates
 :name, presence: true validates :brewery, presence: true validates :style,
 presence: true validates :abv, presence: true end</pre>But this accomplishes
 the same thing:<pre>validates :name, :brewery, :style, :abv, presence: true</pre>If
 we want to check to see if a beer is already in our database, we can use “uniqueness”,
 but some brewers just name their beers after the style, and we might want to keep
 track of different vintages of the same beer separately.<pre>validates :name,
 uniqueness: { scope: [:brewery, :vintage] }</pre>Passing the “scope” option to
 our uniqueness validation allows us to check for a unique combination of properties,
 here ensuring that the same beer name, by a different brewery or of a different
 vintage, will be treated as a unique beer.In other cases, the permitted values
 for one property may depend on the value of another. Here we can use conditional
 validations, for example, making sure the ABV of a beer is within the typical range,
 unless it’s a barleywine, in which case the sky’s the limit:<pre>validates :abv,
 inclusion: { in: 0...30 }, unless: Proc.new { |b| b.style ==
 &quot;barleywine&quot; }</pre><h3>Custom Validations</h3>As you can see, Rails’
 validation helpers are pretty versatile, and in many cases can provide everything
 we need to make sure we’re only accepting properly validated data, but Rails’ magic
 can’t account for every situation.<figure><img alt="" src="https://cdn-images-1.medium.com/max/658/1*9eCJB24Xj96LeIIuNI76NQ.png"
 /></figure>Custom validations are classes that inherit from ActiveModel::Validator
 (you can also write custom methods in your models, and call them using “validate :method_name”),
 allowing you to build whatever functionality you need into your checks, although
 Cueball’s issue illustrated above might be beyond help.More on Active Record
 validations:<a href="https://www.google.com/url?sa=t&amp;rct=j&amp;q=&amp;esrc=s&amp;source=web&amp;cd=1&amp;cad=rja&amp;uact=8&amp;ved=0ahUKEwjSsZnSit3YAhWSUd8KHf4mDKkQFggpMAA&amp;url=http%3A%2F%2Fguides.rubyonrails.org%2Factive_record_validations.html&amp;usg=AOvVaw0r4zKycKCtlitzQA8hIZWm">Rails
 Guides — Validations</a><a href="https://hackernoon.com/performing-custom-validations-in-rails-an-example-9a373e807144">Performing
 Custom Validations in Rails — an Example</a><a href="https://robots.thoughtbot.com/the-perils-of-uniqueness-validations">The
 Perils of Uniqueness Validations</a><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=890519b94fe7"
 width="1" height="1" alt="">'
rss_fields:
- title
- url
- author
- categories
- published
- entry_id
- content
url: https://medium.com/@krandles/active-record-validations-890519b94fe7?source=rss-d451d084d34a------2
author: Kevin Randles

Language

Active

Ricc internal notes

Ricc source

Show this article Back to articles