Active Record Validations
Today I’m going to talk about some of the active record validations, how they are used and what they do but first here’s a glimpse from rubyonrails.org about why validations are a thing.
Validations are used to ensure that only valid data is saved into your database. For example, it may be important to your application to ensure that every user provides a valid email address and mailing address. Model-level validations are the best way to ensure that only valid data is saved into your database. They are database agnostic, cannot be bypassed by end users, and are convenient to test and maintain. Rails makes them easy to use, provides built-in helpers for common needs, and allows you to create your own validation methods as well.
I have used validations in my rails models in the past but mostly the presence and uniqueness validators (Note: These are helpers that come with active record). Let’s take a look at the presence validator first as it is one of the lower level and simple validators to use and implement.
Here’s a note from rubyonrails.org about the presence helper:
This helper validates that the specified attributes are not empty. It uses the
blank?method to check if the value is eithernilor a blank string, that is, a string that is either empty or consists of whitespace.
I’m going to use one of my prior projects as an example here. This was a recipe app. Let’s say in this app I want to validate the user model to make sure the user has a name. So basically, I want to require my users enter a name. To implement this I’m going to add the following line of code to my user model. This does exactly what we want, it requires our user to validate (or enter) their name.
Okay, this is great but what if our users are rebels and don’t comply, what happens then? There are default error messages with these validation helpers and for presence it is “can’t be empty”. So if you user tries to proceed without a name they will receive that error.
One of the other models I have in my project is a comment model. I validated the length of the content in this model. I set a minimum and a maximum length for the comments. Let me show you how I implemented this. I added the follow two lines of code to my comment model. This validates that a comments content is at least 10 characters in length but no more than 200.
Here’s a note about the default error message for the length validator:
The default error messages depend on the type of length validation being performed. You can personalize these messages using the :wrong_length, :too_long, and :too_short options and {{count}} as a placeholder for the number corresponding to the length constraint being used. You can still use the :message option to specify an error message.
Okay, now that we have covered a couple of the more simple validators what about customized validators? In my app I wanted the recipe to be title cased. However, I couldn’t find an active record validator for that so I had to customize my own validator method for this. To accomplish this I wrote a couple method in my Recipe model. You can check them out below.
Okay, great we have our custom title case method but that doesn’t tell us how to implement the custom validator. Let’s check that out now. It’s pretty simple actually, you have already done the complicated part by writing the custom method, now we just need to pass that info on to the validator. Check the snipped below for how you can pretty easily accomplish this.
I think active record validators are a great way to make sure you are getting valid data in your database and for the most part it’s pretty simple to implement them. I recommend checking out the guides on validators here and try implementing some of the others into your own projects!
Sources:
https://guides.rubyonrails.org/v2.3/activerecord_validations_callbacks.html
Thanks for reading my blog today, I hope it was somewhat useful to you!
Happy Coding!
