For one of my models, I have a few instances that should be auto-populated. How do I handle this?

Question

I have to be specific for this to make sense. In my application I have a model called theme which contains widget color theme information. We provide a few themes, but mainly rely on the user to create their own themes. So the question is: where do I store my themes? If I store them in the theme database, then anytime I switch databases or flush it during testing, I must re-enter the themes in. This is not a huge deal, it just seems sloppy.

Right now I have the themes stored in a Hash in the controller. The problem with that is since each widget has a theme, each widget has a theme_id, and there is no theme_id for our provided themes because they are not stored in the database.

I know that a solution to this issue is pretty simple, but I want to make sure my solution employs the best coding practices. Does anyone have any suggestions for this? Maybe there is a way to add entries into the database during a migration or other rake task...

Thank you!

Tony

Answer 1

The theme data belongs in the database.

For testing, initialize the theme data using fixtures or the setup method. For development and production, you should create a way to seed the database with the initial theme data. A custom Rake task is good for this. The actual theme data can be stored in any format you wish, really. For example SQL scripts or YML fixtures.

I use the following Rake task to seed the database with data held in SQL files within db/seeddata (put this in a .rake file under your project's /lib directory):

namespace :db do
  desc "Load seed fixtures (from db/seeddata) into the current environment's database." 
  task :seed => :environment do
    require 'yaml'
    config = YAML::load(open("#{RAILS_ROOT}/config/database.yml"))["#{RAILS_ENV}"]
    Dir.glob(RAILS_ROOT + '/db/seeddata/*.sql').each do |file|
      cmd = "mysql -u #{config['username']} -p#{config['password']} -h #{config['host']} #{config['database']} < #{file}"
      `#{cmd}`
    end
  end
end

Answer 2

Your idea to seed the data seems like the way to go. I like the method you proposed, but what do you think of the method proposed here: http://railspikes.com/2008/2/1/loading-seed-data

It suggests that you let ActiveRecord handle seeding the data so that it can validate the data.

Which do you think is better?

Thanks again!

Tony

Answer 3

Loading seed data in the migrations makes the most sense and is something I have done often. If creating those first few records is truly part of the proper initialization of your table, i.e. if your table simply will no do the job you need in your application without them, then they belong in the migration. Rake tasks are great for capturing data sets that you need to load into the application on command (for example for a demo), but if certain records are going to be consistently required, the migration is the spot.