[ACCEPTED]-How (and whether) to populate rails application with initial data-data-migration

Try a rake task. For example:

1. Create the file /lib/tasks/bootstrap.rake
2. In the file, add a task to create your default user:

    namespace :bootstrap do
      desc "Add the default user"
      task :default_user => :environment do
        User.create( :name => 'default', :password => 'password' )
      end

      desc "Create the default comment"
      task :default_comment => :environment do
        Comment.create( :title => 'Title', :body => 'First post!' )
      end

      desc "Run all bootstrapping tasks"
      task :all => [:default_user, :default_comment]
    end

3. Then, when you're setting up your app for the first time, you can do rake db:migrate OR rake db:schema:load, and then do rake bootstrap:all.

0

Use db/seed.rb found in every Rails application.

While 11 some answers given above from 2008 can work 10 well, they are pretty outdated and they 9 are not really Rails convention anymore.

Populating 8 initial data into database should be done 7 with db/seed.rb file.

It's just works like a Ruby file.

In 6 order to create and save an object, you 5 can do something like :

User.create(:username => "moot", :description => "king of /b/")

Once you have this 4 file ready, you can do following

rake db:migrate

rake db:seed

Or in one 3 step

rake db:setup

Your database should be populated with 2 whichever objects you wanted to create in 1 seed.rb

I recommend that you don't insert any new data 9 in migrations. Instead, only modify existing 8 data in migrations.

For inserting initial 7 data, I recommend you use YML. In every 6 Rails project I setup, I create a fixtures 5 directory under the DB directory. Then 4 I create YML files for the initial data 3 just like YML files are used for the test 2 data. Then I add a new task to load the 1 data from the YML files.

lib/tasks/db.rake:

namespace :db do
  desc "This loads the development data."
  task :seed => :environment do
    require 'active_record/fixtures'
    Dir.glob(RAILS_ROOT + '/db/fixtures/*.yml').each do |file|
      base_name = File.basename(file, '.*')
      say "Loading #{base_name}..."
      Fixtures.create_fixtures('db/fixtures', base_name)
    end
  end

  desc "This drops the db, builds the db, and seeds the data."
  task :reseed => [:environment, 'db:reset', 'db:seed']
end

db/fixtures/users.yml:

test:
  customer_id: 1
  name: "Test Guy"
  email: "test@example.com"
  hashed_password: "656fc0b1c1d1681840816c68e1640f640c6ded12"
  salt: "188227600.754087929365988"

This is my new favorite solution, using 1 the populator and faker gems:

http://railscasts.com/episodes/126-populating-a-database

Try the seed-fu plugin, which is quite a simple 4 plugin that allows you to seed data (and 3 change that seed data in the future), will 2 also let you seed environment specific data 1 and data for all environments.

I guess the best option is number 3, mainly 3 because that way there will be no default 2 user which is a great way to render otherwise 1 good security useless.

I thought I'd summarise some of the great 23 answers I've had to this question, together 22 with my own thoughts now I've read them 21 all :)

There are two distinct issues here:

1. Should I pre-populate the database with my special 'admin' user? Or should the application provide a way to set up when it's first used?
2. How does one pre-populate the database with data? Note that this is a valid question regardless of the answer to part 1: there are other usage scenarios for pre-population than an admin user.

For 20 (1), it seems that setting up the first 19 user from within the application itself 18 is quite a bit of extra work, for functionality 17 which is, by definition, hardly ever used. It 16 may be slightly more secure, however, as 15 it forces the user to set a password of 14 their choice. The best solution is in between 13 these two extremes: have a script (or rake 12 task, or whatever) to set up the initial 11 user. The script can then be set up to 10 auto-populate with a default password during 9 development, and to require a password to 8 be entered during production installation/deployment 7 (if you want to discourage a default password 6 for the administrator).

For (2), it appears 5 that there are a number of good, valid solutions. A 4 rake task seems a good way, and there are 3 some plugins to make this even easier. Just 2 look through some of the other answers to 1 see the details of those :)

Consider using the rails console. Good 7 for one-off admin tasks where it's not worth 6 the effort to set up a script or migration.

On 5 your production machine:

script/console production

... then ...

User.create(:name => "Whoever", :password => "whichever")

If you're 4 generating this initial user more than once, then 3 you could also add a script in RAILS_ROOT/script/, and 2 run it from the command line on your production 1 machine, or via a capistrano task.

That Rake task can be provided by the db-populate 1 plugin:

http://github.com/joshknowles/db-populate/tree/master

Great blog post on this: http://railspikes.com/2008/2/1/loading-seed-data

I was using Jay's 4 suggestions of a special set of fixtures, but 3 quickly found myself creating data that 2 wouldn't be possible using the models directly 1 (unversioned entries when I was using acts_as_versioned)

I'd keep it in a migration. While it's recommended 7 to use the schema for initial setups, the 6 reason for that is that it's faster, thus 5 avoiding problems. A single extra migration 4 for the data should be fine.

You could also 3 add the data into the schema file, as it's 2 the same format as migrations. You'd just 1 lose the auto-generation feature.

For users and groups, the question of pre-existing 13 users should be defined with respect to 12 the needs of the application rather than 11 the contingencies of programming. Perhaps 10 your app requires an administrator; then 9 prepopulate. Or perhaps not - then add code 8 to gracefully ask for a user setup at application 7 launch time.

On the more general question, it 6 is clear that many Rails Apps can benefit 5 from pre-populated date. For example, a 4 US address holding application may as well 3 contain all the States and their abbreviations. For 2 these cases, migrations are your friend, I 1 believe.

Some of the answers are outdated. Since 10 Rails 2.3.4, there is a simple feature called 9 Seed available in db/seed.rb :

#db/seed.rb
User.create( :name => 'default', :password => 'password' )
Comment.create( :title => 'Title', :body => 'First post!' )

It provides a new rake 8 task that you can use after your migrations 7 to load data :

rake db:seed

Seed.rb is a classic Ruby 6 file, feel free to use any classic datastructure 5 (array, hashes, etc.) and iterators to add 4 your data :

["bryan", "bill", "tom"].each do |name|
  User.create(:name => name, :password => "password")
end

If you want to add data with 3 UTF-8 characters (very common in French, Spanish, German, etc.), don't 2 forget to add at the beginning of the file 1 :

# ruby encoding: utf-8

This Railscast is a good introduction : http://railscasts.com/episodes/179-seed-data