Data loading is done for 2 purposes: First, to load data that will seed the system for ongoing use and that will live in the production environment, and second, to use for system testing. These two types of data are stored in two different ways.

Loading ‘seed’ data that will be required in production.

This data should be defined in /db/seeds.rb and loaded using the rake db:seed command. It should be loaded one time after initial database creation. If changes to the seeds.rb file are made, the database should be rebuilt and reloaded from scratch.

Loading test data.

This is data that is required for testing the application. Specifically, it is data that should not appear in the production application.

This data should be loaded through model classes (or using factory_girl or similar) in a ‘rake’ file, for example /lib/tasks/test_data.rake and then load it using the rake task rake app:load_demo_data. Similar to loading seeds.rb, if the test data changes then the database should be reloaded from scratch.

(Note that here the rake file is named /lib/tasks/test_data.rake and the rake task to load the data is rake app:load_demo_data. This would vary based on what you felt was an appropriate name for your project.)

Overall database loading/unloading

The correct way to load data into the database is to use the following rake commands:

rake db:drop db:create db:migrate db:seed app:load_demo_data

As you see, multiple rake commands can be run one after another sequenced on the same line.

This should be able to be done at any time by any person in development. If you make a change to any data, please assume that the above sequence of rake commands could be run at any time and all data could be replaced.

Note also that the above command will load data into the ‘development’ instance of your database. If you need to load (or reload) the production or test environments, then precede this command with the appropriate RAILS_ENV like so:

RAILS_ENV=test rake db:drop db:create db:migrate db:seed app:load_demo_data

Here’s an example of what the rake file /lib/tasks/test_data.rake might look like:


namespace :app do
  desc <<-DESC
    Load testing data.
    Run using the command 'rake app:load_demo_data'
  DESC
  task :load_demo_data => [:environment] do

  end
end


You have an attribute that can be a set of specific values, like the status of a transaction that can be ‘processing’, ‘succeeded’ or ‘failed’.  You now want to make it easy to check these values on your model object and you think you might want to create a named scope for one of more of them.

Here’s a simple ‘design pattern’ that makes this easy and fast.

First, define a Module within your Class and use it to define constants for the allowed values, then put those values in an Array. This tightens up the code by encouraging developers to only set that attribute to one of the ‘predefined’ values. For example:

class Transaction < ActiveRecord::Base

  # Allowed values for attribute 'status'
  module Status
    PROCESSING = 'processing'
    SUCCEEDED   = 'succeeded'
    FAILED     = 'failed'
  end
  STATUSES = [Status::PROCESSING, Status::SUCCEEDED, Status::FAILED]

end

This is a simple ‘design pattern’ that encourages the use of good practices in development.

Now that we’ve got this in place, let’s spin up some ruby magic to automate the creation of status methods and named scopes for each of the different values. We’ll do so with this bit of code:

STATUSES.each do |status|
   # Define a 'setter' method for each status value
   define_method "#{status}!".to_sym do
     self.status = status
   end
   # Define an 'interrogator' method for each status value
   define_method "#{status}?".to_sym do
     self.status == status
   end
  # Define a named scope for each status value
   self.named_scope status.to_sym, :conditions => { :status => status }
 end

It’s part of the magic of Ruby that classes can so easily extend themselves by adding new methods.

And if you change the allowed values for the ‘status’ field, simply modify the Module definition and add the new value to the array — creation of named scopes and the other methods will be taken care of automatically.

Sometimes when using Active Record you may want to create a database connection to a database other than the default database specified in your database.yml file.

When this happens, the easiest way to do it is to use the Class-level convenience method on ActiveRecord::Base. Like this:

Imagine your database.yml entry looks like this:

development_foo:
  adapter: mysql
  encoding: utf8
  database: foo
  pool: 5
  username: my_user
  password: my_pass
  socket: /tmp/mysql.sock

Now you want to create active record models that use that database connection. Here’s how:

# 'Bar' model points to the table 'bars' in the database 'foo'

class Bar < ActiveRecord::Base

  # specify the database.yml entry
  $db_config = 'development_foo'

  # Fetch the database.yml configuration
  $config = ActiveRecord::Base.configurations[$db_config]

 # Now we can establish a connection to that database and
 # this ActiveRecord model class will point to that database.
  establish_connection $config

end

It’s simple!

Copyright Kevin Bedell, 2009
All this code can be freely used under the terms of the MIT License.