Rake migration issue

Rails
1

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

– create_table(:incident_users)
rake aborted!
Mysql::Error: Table ‘incident_users’ already exists:

So I thought I would see if anyone has more of a clue than I do before
falling back on the MYSQL command line editor just to get things
moving along.

Thanks much,
Bill

2

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 S…

Pablo
Picassohttp://www.brainyquote.com/quotes/authors/p/pablo_picasso.html

  • “Computers are useless. They can only give you answers.”
3

2009/8/31 zambezi [email protected]:

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

– create_table(:incident_users)
rake aborted!
Mysql::Error: Table ‘incident_users’ already exists:

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

4

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

5

2009/8/31 zambezi [email protected]:

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

6

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
end

def self.down
drop_table :incident_user
end

end #end migration

7

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?

8

2009/8/31 zambezi [email protected]:

Cheers, Bill
   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

9

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

10

2009/8/31 zambezi [email protected]:

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