------------------------------
Title: Active Record Validations
[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.You probably won’t break the internet if you do this, but are you willing to take that risk?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.Enter data validationBuilding 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.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 validation helpers. 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?class User < ApplicationRecord  validates :name, presence: trueendPerson.create(name: "Beef Supreme").valid? # => truePerson.create(name: nil).valid? # => falseIf 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?class Account < ApplicationRecord  validates :email, uniqueness: trueend“uniqueness: true” will check to see if Beef has already registered his email address and, if so, generates an error message:beef.supreme@brawndo.com has already been takenI 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:create_table "beers", force: :cascade do |t|  t.string   "name"  t.string   "brewery"  t.string   "style"  t.float    "abv"  t.text     "description"  t.integer  "vintage"endValidating 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:class Beer < ActiveRecord::Base  validates :name, presence: true  validates :brewery, presence: true  validates :style, presence: true  validates :abv, presence: trueendBut this accomplishes the same thing:validates :name, :brewery, :style, :abv, presence: trueIf 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.validates :name, uniqueness: { scope: [:brewery, :vintage] }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:validates :abv, inclusion: { in: 0...30 },                unless: Proc.new { |b| b.style == "barleywine" }Custom ValidationsAs 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.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:Rails Guides — ValidationsPerforming Custom Validations in Rails — an ExampleThe Perils of Uniqueness Validations
[/content]

Author: Kevin Randles
PublishedDate: 2018-01-16
Category: Technology
NewsPaper: Kevin Randles on Medium
Tags: ruby-on-rails, flatiron-school