Rake migration issue

I've encountered a problem running Rake migrations. This is in a fresh database (no prior migrations run).

001_create_incident_users 002_create_incidents

Running db:migration resulted in table incident_users being successfully created, but Rake then aborted before migrating/creating the second table.

So I then tried the following three permutations to coax a successful migration of the incident table and got the same result each time. Basically an incident_user migration is run (rather than incident) and then the process aborts. The log file didn't have anything further to offer.

db:migration db:migration incidents db:migration VERSION=002

(in C:/RubyRails/rails_apps/rappEAHv8) == 2 CreateIncidentUsers: migrating

You can try to do a ‘rake db:drop’ to drop all tables, then do a ‘rake db:create’ and then finally again do ‘rake db:migrate’ Regarding the error in your second rake file, can you please share the migration code within that file ?

Thanks & Regards, Dhruva Sagar.

Pablo Picasso - “Computers are useless. They can only give you answers.”

This sort of thing is unfortunately not that uncommon. The issue is that the migration failed for some reason half way through, after creating the incident_users table but before completeing the migration. When you run the migration again it starts from the beginning of the file and attemts to create the table, but it already exists hence the error. If you delete the incident_users table manually then try again you will get the original error message again which may tell you more.

Colin

Hello Dhruva and Colin,

Thanks much for your responses. I think my latest reply went to Colin's email since it hasn't shown up on the discussion list, so I will recap. I dropped and recreated the db and reran the migrations. Unfortunately to the same end with Rake aborting after the first migration.

Don't think it is a migration code issue since I can reverse the migration order and still have the first table created followed by Rake aborting on the 2nd.

Cheers, Bill

Don't think it is a migration code issue since I can reverse the migration order and still have the first table created followed by Rake aborting on the 2nd.

Actually, that tells me that you might have the same problem in both migrations. Its' possible that you have an exit condition in your migration code that's causing the error. How about showing the code?

Thanks Dhruva and Colin,

I dropped the database and then recreated it. Rake threw up an abort message, but still created the db. Next I ran the migration, but rake still aborted with out creating the 2nd table. I don't think it is the migration code, because I tried reversing the migration order (table incident and then table incident user). Table incident was created, but Rake aborted on incident_user.

--------Here are the messages

on db:create db_eahv8

You just want rake db:create It knows the db name from database.yml

Get this working before worrying about the next bit as if this won't work there is something fundamentally wrong.

Colin

Hi Dhruva and Colin,

Ran Rake again to drop and recreate the db without a specific name reference. As before the db was created, although no errors or protests this time. However subsequently running the migration was deja vue. Below is the migration code. It looks straight forward to me, but if I knew what to look for I wouldn't be here.

Cheers, Bill

Hi Dhruva and Colin,

Ran Rake again to drop and recreate the db without a specific name reference. As before the db was created, although no errors or protests this time. However subsequently running the migration was deja vue. Below is the migration code. It looks straight forward to me, but if I knew what to look for I wouldn't be here.

Cheers, Bill

----------

class CreateIncidentUsers < ActiveRecord::Migration

def self.up create_table :incident_user do |t| t.column :incident_user_name, :string, :null => false t.column :position, :string t.column :phone, :string t.column :email, :string, :null => false t.column :hashed_password, :string, :null => false t.column :salt, :string t.column :enabled, :boolean, :default => true, :null => false t.column :last_login_at, :datetime t.timestamps end add_index :incident_user_name

add_index takes 2 parameters, table name and column name.

The clue was in the error message

By the way you are using the old format for specifying columns, it still works but probably best to use the latest technique.

Colin

Hi Colin,

I added the table reference for the indexes, reran everything and the migration went through fine. Thank you for spotting the problem and thanks to you and Dhruva for bearing with me.

As for my antiquated syntax, there is a lot of that. I appreciate the pointer and assume you mean:

t.string :name

instead of

t.column :name, :string

Cheers, Bill

Hi Colin,

I added the table reference for the indexes, reran everything and the migration went through fine. Thank you for spotting the problem and thanks to you and Dhruva for bearing with me.

Glad to be of help, I should have spotted it earlier really. I don't know why the error did not specify a line number which would have helped, normally I would expect a stack trace that would have shown this.

As for my antiquated syntax, there is a lot of that. I appreciate the pointer and assume you mean:

t.string :name

instead of

t.column :name, :string

Yes, to be honest I found the earlier syntax more intuitive but this seems to be the recommended way so I decided to switch over to it. No need to change existing code though.

Colin