Example of a load_data.rb file

class LoadData < ActiveRecord::Migration
  def up
    # Create initial users.
    down
    jb = User.new(:first_name => "Justin", :last_name => "Bieber")
    jb.save(:validate => false)
    ph = User.new(:first_name => "Paris",  :last_name => "Hilton")
    ph.save(:validate => false)
    mc = User.new(:first_name => "Miley",  :last_name => "Cyrus")
    mc.save(:validate => false)
    bo = User.new(:first_name => "Barack", :last_name => "Obama")
    bo.save(:validate => false)
    sc = User.new(:first_name => "Santa", :last_name => "Claus")
    sc.save(:validate => false)
    jo = User.new(:first_name => "John", :last_name => "Ousterhout")
    jo.save(:validate => false)

 end

  def down
    User.delete_all
  end
end

From RoR guide:

What are Schema Files for? (YOU DONT EDIT THEM!!!!!)

Migrations, mighty as they may be, are not the authoritative source for your database schema. That role falls to either db/schema.rb or an SQL file which Active Record generates by examining the database. They are not designed to be edited, they just represent the current state of the database.

There is no need (and it is error prone) to deploy a new instance of an app by replaying the entire migration history. It is much simpler and faster to just load into the database a description of the current schema.

For example, this is how the test database is created: the current development database is dumped (either to db/schema.rb or db/structure.sql) and then loaded into the test database.

Schema files are also useful if you want a quick look at what attributes an Active Record object has. This information is not in the model's code and is frequently spread across several migrations, but the information is nicely summed up in the schema file. The annotate_models gem automatically adds and updates comments at the top of each model summarizing the schema if you desire that functionality.

Because schema dumps are the authoritative source for your database schema, it is strongly recommended that you check them into source control.

db/schema.rb contains the current version number of the database. This ensures conflicts are going to happen in the case of a merge where both branches touched the schema. When that happens, solve conflicts manually, keeping the highest version number of the two.

Example schema.rb file created from above

ActiveRecord::Schema.define(version: 20150105235326) do

  create_table "users", force: :cascade do |t|
    t.string   "first_name"
    t.string   "last_name"
   
  end

end

                

 

From RoR guide:

Occasionally you will make a mistake when writing a migration. If you have already run the migration then you cannot just edit the migration and run the migration again: Rails thinks it has already run the migration and so will do nothing when you run rake db:migrate. You must rollback the migration (for example with rake db:rollback), edit your migration and then run rake db:migrate to run the corrected version.

In general, editing existing migrations is not a good idea. You will be creating extra work for yourself and your co-workers and cause major headaches if the existing version of the migration has already been run on production machines. Instead, you should write a new migration that performs the changes you require. Editing a freshly generated migration that has not yet been committed to source control (or, more generally, which has not been propagated beyond your development machine) is relatively harmless.

The revert method can be helpful when writing a new migration to undo previous migrations in whole or in part (see Reverting Previous Migrations above).

NOT a suggestion but on the command line there is a

db:migrate:redo

and 
rake db:schema:dump

Quickly generate new migrations file to add say a new column in a table

rails generate migration add_columnname_to_tablename

example

rails generate migration add_gpa_to_students

The timestamps macro adds two columns, created_at and updated_at.

• Both will be of the data type datetime.
• These special columns are automatically managed by Active Record if they exist.   Ofcourse editing by hand requires input