Don’t go re-creating your DB! The whole point of Migrations is simple,
manageable, incremental evolution of the schema that stays in sync on
all the databases you’re running the app on. Adding or dropping tables,
adding or deleting fields, all of this should be done in subsequent
You have that initial migration that creates your first handful of
tables. Then your next migration might just add a field. Run that
migration. The one after that might add two more fields and another
couple of tables. Run that migration. A later migration might add an
index you forgot to create earlier, or alter the default value of a
field, or replace one kind of field with another and convert the values
from the old field to the new one, etc. Then when you move your app to
deployment, or another developer starts working with the source on her
own machine, all that’s needed to get an identical database schema on
that machine is one “rake migrate”. Got another development box that has
a database schema several months behind? “Rake migrate” brings it up to
speed by running all the migrations that haven’t been run already.
So if you want to add a field to Accounts, this is when you create a new
migration that adds the field. Pretty much the only time you should ever
think of editing a migration that’s already been run is if you’re early
in your app’s development and your schema is being so radically reworked
from the ground up that you want to wipe the whole thing, drop the
database, data and all, and start fresh.
John Q. wrote:
I’m new to both Rails and Ruby. I have a couple of very basic questions.
I have a migration for Accounts, but I need to add another field. If
I simply add it to my 001_accounts.rb file, and re-run rake migrate,
nothing happens. The new field doesn’t get added. I’ve been looking on
the web but can’t find a good way to do this.
How to I prime my database after creation? I want to start out with a
set of default data, and was wondering where the best place to do this