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
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<http://www.brainyquote.com/quotes/authors/p/pablo_picasso.html> - "Computers are useless. They can only give you answers." On Mon, Aug 31, 2009 at 9:43 PM, zambezi <b.butler-GrTI0ftTvuWGJGYlWa3Ukdi2O/JbrIOy@public.gmane.org> wrote:> > 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 > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
2009/8/31 zambezi <b.butler-GrTI0ftTvuWGJGYlWa3Ukdi2O/JbrIOy@public.gmane.org>:> > 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: >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?
2009/8/31 zambezi <b.butler-GrTI0ftTvuWGJGYlWa3Ukdi2O/JbrIOy@public.gmane.org>:> 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_eahv8You 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> > (in C:/RubyRails/rails_apps/rappEAHv8) > rake aborted! > Don''t know how to build task ''db_eahv8'' > > on db:migrate > > (in C:/RubyRails/rails_apps/rappEAHv8) > == 1 CreateIncidentUsers: migrating > ==========================================> -- create_table(:incident_user) > -> 0.0800s > -- add_index(:incident_user_name) > rake aborted! > wrong number of arguments (1 for 2) > > -------- > 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
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
2009/8/31 zambezi <b.butler-GrTI0ftTvuWGJGYlWa3Ukdi2O/JbrIOy@public.gmane.org>:> > 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_nameadd_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> end > > def self.down > drop_table :incident_user > end > > end #end migration > > >
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
2009/8/31 zambezi <b.butler-GrTI0ftTvuWGJGYlWa3Ukdi2O/JbrIOy@public.gmane.org>:> > 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, :stringYes, 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