Rails Validations

After spending a lot of time diving deeper into a couple other languages and frameworks, I recently returned to Ruby on Rails to build a new project. And after a little time away, I was once again blown away by the ease and ‘magic’ of Rails. It truly is a beast of a framework: incredibly intuitive, well thought-out, and full of developer friendly features and helpers.

While there are many features that deserve attention, I was particularly impressed with the implementation of Active Record Validations.

Active Record Validations are built to ensure that only good data is saved to the database. They are an effective way to do things like ensure that 2 users don’t wind up with the same user name or that the password that a user creates doesn’t contain a typo. And while there are other ways to ensure that invalid data doesn’t get saved to the database, Active Record Validations are usually the safest bet and are recommended by the Rails team in most scenarios.

Validations get triggered by several different methods and perhaps one of the most important times you want to check for valid data is when you are creating a new row in your database-such as a new User. In this case, validation checks get triggered when using the .save and/or .create methods.

For example, if you wanted to create a new User at signup and ensure that their email address was not being used by another user, you would first add this code to your User Model:

class User < ApplicationRecord
   validates :email, uniqueness: true
end

Now, when you try to .save the record to the database, your validation will get triggered, and before an SQL INSERT operation is executed, Active Record will check to make sure that no other User exists who has that same email address! If the email exists, an error will be added to the ruby object’s errors collection and will be associated with it for future use (such as displaying the error to the user when validation fails).

Another great validation is :confirmation. This validation is perfect for making sure that the User typed in their email or password correctly. According to the docs, this validation will create a virtual attribute associated with the real attribute with _confirmation appended to the field’s name (ie. email_confirmation.

To implement as password confirmation, you might add this to your model:

class User
   validates :password, confirmation: true
   validates :password_confirmation, presence: true
end

The first line creates the virtual _confirmation attribute and will check to ensure that the :password and :password_confirmation fields match. (note: your confirmation field on your form must have the _confirmation virtual attribute as its ID. In this case: :password_confirmation). However, the validation will only get triggered if the password_confirmation value is NOT nil. Therefore, for extra bad-data protection, the second line:

validates :password_confirmation, presence: true

exists so that a user doesn’t skip the password confirmation field and submit the form-even if their password contains an unintended keystroke.

These are only 2 simple examples of the amazing Validation helpers included with Active Record in Rails. There are many other validations and many ways to use them, combine them, and/or skip them altogether. They are so useful and easy to implement that I had never given them a second thought. But it’s great to step back, examine how they work, and fully appreciate what a beneficial and efficient tool they are for developers.