Rails migrations and model validations
November 03, 2008
So Rails has a feature called “migrations”. The idea here is that your database will change over time and you need a way to change this incrementally as the project changes and new requirements come up. So essentially your database moves through time.
Rails also has a feature where you can define validations for a field at the model level (aka: application level, vs database level, validations): make sure it is defined, is in a certain range, etc. These are declarative statements, meaning that they are set up when the class is defined and ran when an instance is created.
In certain situations, however, there comes an issue with this. For example, if you’re using Cruise Control to do integration tests, you might find that you’re migrating down to the first migration and then migrating all the way back up to current. Which is fine and a good practice, except for one thing: your model validations don’t move through time with your migrations. This is no problem… unless you’re trying to create or modify records using these model objects in your migrations. Then you have a paradox: the model tries to validate a field, but was given no value because that field doesn’t exist yet.
Lets say in migration 2 we are creating vendors and populating some default ones: `class CreateVendors < ActiveRecord::Migration def self.up create_table :vendors do |t| t.string :name t.string :email end a = Vendor.new(:name => “Fred Flinstone”, :email => ”fred@example.com”) a.save! b = Vendor.new(:name => “Barney Ruble”, :email => ”barney@example.com”) b.save end
def self.down drop_table :vendors end end`
But we”ve been developing the app for some time, and in migration 20 we add a rating field to the Vendor table, as well as the following validation to the model:
validates_presence_of :rating, :on => :create, :message => "can't be blank"
Now when we migrate down to 0 and migrate back up, we get an error in migration 2: `$ rake db:migrate (in … ) == 2 CreateVendors: migrating ======================================= rake aborted! Validation failed: Rating can’t be blank
(See full trace by running task with —trace)`
Oops! We’re validating something that doesn’t exist yet!!
Rails saves the day again, because each validation_ declaration has an :if
parameter, which should be a Symbol or Procedure to run. If this symbol or procedure method returns true, then the validation is run.
So our problem can be solved by changing the model validation to read: validates_presence_of :rating, :on => :create, :message => "can't be blank", :if => Proc.new { |record| record.respond_to? :rating }
responds_to
asks the Rails model: “Do you have a method named ‘rating’?“. Because Rails magically creates methods for every column an entity has in the database, Rails will either have that method (because it has been defined in the database), or not (because no such column exists). So we only run the validation if we have the column, avoiding the mess with trying to validate data that doesn’t make sense (yet).