Newbie Question

Rails
1

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.

2

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.

3

On 4/15/06, John Q. [email protected] 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.

4

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.

5

Here here for the YAML method.

Fill up your fixtures ( and remove the default ones ) and then…

rake db:fixtures:load

6

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.

7

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

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.