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