# Newbie Question **URL:** \ **Category:** Rails\ **Created:** [April 15, 2006, 7:47pm UTC](https://www.ruby-forum.com/t/newbie-question/93944 "2006-04-15T19:47:03Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![johnquinley](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e36b37/32.png) [@johnquinley](https://www.ruby-forum.com/u/johnquinley)\ **Post date:** [April 15, 2006, 7:47pm UTC](https://www.ruby-forum.com/t/newbie-question/93944/1 "2006-04-15T19:47:03Z")
Hi, I’m new to both Rails and Ruby. I have a couple of very basic questions. 1. 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. 2. 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 is. Thanks. ---
**Author:** ![johnquinley](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e36b37/32.png) [@johnquinley](https://www.ruby-forum.com/u/johnquinley)\ **Post date:** [April 15, 2006, 7:56pm UTC](https://www.ruby-forum.com/t/newbie-question/93944/2 "2006-04-15T19:56:34Z")
On Apr 15, 2006, at 10:47 AM, John Q. wrote: > I’m new to both Rails and Ruby. I have a couple of very basic > questions. > > 1. 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. Destroy and recreate your DB. Migrations are intended to be applied serially. The migrations system creates a table called schema\_info that tracks migration version and uses it to determine which migrations need to be run. > 1. 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 > is. A higher numbers migration with Model.create statements. – – Tom M. ---
**Author:** ![johnquinley](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e36b37/32.png) [@johnquinley](https://www.ruby-forum.com/u/johnquinley)\ **Post date:** [April 15, 2006, 7:56pm UTC](https://www.ruby-forum.com/t/newbie-question/93944/3 "2006-04-15T19:56:39Z")
On 4/15/06, John Q. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Hi, > > I’m new to both Rails and Ruby. I have a couple of very basic questions. > > 1. 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. Just do another migration. ruby script/generate migration AddWhateverToAccounts …and then, in the migration: add\_column :accounts, :some\_column\_name, :some\_column\_type > 1. 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 > is. You can use your regular models inside the migrations, as long as they already exist. ruby script/generate migration CreateDefaultData Account.create! :name =\> ‘something’, :other\_attribute =\> ‘whatever’, :widgets =\> 5 If you have a lot of them, you could load them from YAML during the migration, rather than typing them all out. ---
**Author:** ![johnquinley](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e36b37/32.png) [@johnquinley](https://www.ruby-forum.com/u/johnquinley)\ **Post date:** [April 15, 2006, 11:56pm UTC](https://www.ruby-forum.com/t/newbie-question/93944/4 "2006-04-15T23:56:57Z")
Thanks guys for all your help. I ended up just dropping the database, re-creating it, and then re-running rake migrate. I added my primer to the end of the self.up method for the tables I wanted to fill. ---
**Author:** ![johnquinley](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e36b37/32.png) [@johnquinley](https://www.ruby-forum.com/u/johnquinley)\ **Post date:** [April 16, 2006, 3:21pm UTC](https://www.ruby-forum.com/t/newbie-question/93944/5 "2006-04-16T15:21:40Z")
Here here for the YAML method. Fill up your fixtures ( and remove the default ones ) and then… rake db:fixtures:load ---
**Author:** ![johnquinley](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e36b37/32.png) [@johnquinley](https://www.ruby-forum.com/u/johnquinley)\ **Post date:** [April 16, 2006, 3:56pm UTC](https://www.ruby-forum.com/t/newbie-question/93944/6 "2006-04-16T15:56:51Z")
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 migrations. 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: > Hi, > > I’m new to both Rails and Ruby. I have a couple of very basic questions. > > 1. 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. > > 2. 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 > is. > > Thanks. ---
**Author:** ![johnquinley](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e36b37/32.png) [@johnquinley](https://www.ruby-forum.com/u/johnquinley)\ **Post date:** [April 16, 2006, 5:03pm UTC](https://www.ruby-forum.com/t/newbie-question/93944/7 "2006-04-16T17:03:12Z")
I am in the “early database changes radically” phase that you describe. I prefer to edit my earlier migrations and the type: rake migrate VERSION=0 followed by rake migrate or some combination of the above to bounce between the two migrations that matter. To me it is easier to work entirely within the rails world than to jump to the db app to drop the db and recreate it. Just my two pennies. Also, see this tip on using your models in migrations: [http://rails.techno-weenie.net/tip/2006/2/23/safely\_using\_models\_in\_migrations](http://rails.techno-weenie.net/tip/2006/2/23/safely_using_models_in_migrations) I use this method to generate basic data for my new tables in each migration. This means I can migrate up and down my chain and always have basic development data to play around with. I also use the recipe in Rails Recipes for dumping my development data (created as described above) into my test fixtures. I think this is a very DRY approach and since migrations are Ruby I can still use techniques from YML test fixtures to generate large amounts of test data during the migration.