My migrations are causing SQL problems

Rails
1

I am running: rake db:migrate, and I am getting this error. I am some
what of a beginner, and I can’t seem to understand migrations, because
I can’t fix this problem :frowning:

== 2 CreateWorks: migrating

– create_table(:works)
rake aborted!
Mysql::Error: #42S01Table ‘works’ already exists: CREATE TABLE works
(id int(11) DEFAULT NULL auto_increment PRIMARY KEY, created_at
datetime DEFAULT NULL, updated_at datetime DEFAULT NULL)
ENGINE=InnoDB

(See full trace by running task with --trace)

The Trace is below:
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:migrate
== 2 CreateWorks: migrating

– create_table(:works)
rake aborted!
Mysql::Error: #42S01Table ‘works’ already exists: CREATE TABLE works
(id int(11) DEFAULT NULL auto_increment PRIMARY KEY, created_at
datetime DEFAULT NULL, updated_at datetime DEFAULT NULL)
ENGINE=InnoDB
/Library/Ruby/Gems/1.8/gems/activerecord-2.0.2/lib/active_record/
connection_adapters/abstract_adapter.rb:150:in log' /Library/Ruby/Gems/1.8/gems/activerecord-2.0.2/lib/active_record/ connection_adapters/mysql_adapter.rb:281:inexecute’
/Library/Ruby/Gems/1.8/gems/activerecord-2.0.2/lib/active_record/
connection_adapters/abstract/schema_statements.rb:104:in
create_table' /Library/Ruby/Gems/1.8/gems/activerecord-2.0.2/lib/active_record/ connection_adapters/mysql_adapter.rb:416:increate_table’
/Library/Ruby/Gems/1.8/gems/activerecord-2.0.2/lib/active_record/
migration.rb:285:in send' /Library/Ruby/Gems/1.8/gems/activerecord-2.0.2/lib/active_record/ migration.rb:285:inmethod_missing’
/Library/Ruby/Gems/1.8/gems/activerecord-2.0.2/lib/active_record/
migration.rb:265:in say_with_time' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/ 1.8/benchmark.rb:293:inmeasure’
/Library/Ruby/Gems/1.8/gems/activerecord-2.0.2/lib/active_record/
migration.rb:265:in say_with_time' /Library/Ruby/Gems/1.8/gems/activerecord-2.0.2/lib/active_record/ migration.rb:281:inmethod_missing’
./db/migrate//002_create_works.rb:3:in up_without_benchmarks' /Library/Ruby/Gems/1.8/gems/activerecord-2.0.2/lib/active_record/ migration.rb:219:insend’
/Library/Ruby/Gems/1.8/gems/activerecord-2.0.2/lib/active_record/
migration.rb:219:in migrate' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/ 1.8/benchmark.rb:293:inmeasure’
/Library/Ruby/Gems/1.8/gems/activerecord-2.0.2/lib/active_record/
migration.rb:219:in migrate' /Library/Ruby/Gems/1.8/gems/activerecord-2.0.2/lib/active_record/ migration.rb:348:inmigrate’
/Library/Ruby/Gems/1.8/gems/activerecord-2.0.2/lib/active_record/
migration.rb:339:in each' /Library/Ruby/Gems/1.8/gems/activerecord-2.0.2/lib/active_record/ migration.rb:339:inmigrate’
/Library/Ruby/Gems/1.8/gems/activerecord-2.0.2/lib/active_record/
migration.rb:307:in up' /Library/Ruby/Gems/1.8/gems/activerecord-2.0.2/lib/active_record/ migration.rb:298:inmigrate’
/Library/Ruby/Gems/1.8/gems/rails-2.0.2/lib/tasks/databases.rake:85
/Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:546:in call' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:546:inexecute’
/Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:541:in each' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:541:inexecute’
/Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:508:in
invoke_with_call_chain' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:insynchronize’
/Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:in
invoke_with_call_chain' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:494:ininvoke’
/Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1931:in
invoke_task' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1909:intop_level’
/Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1909:in each' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1909:intop_level’
/Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1948:in
standard_exception_handling' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1903:intop_level’
/Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1881:in run' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1948:instandard_exception_handling’
/Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1878:in run' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/bin/rake:31 /usr/bin/rake:19:inload’
/usr/bin/rake:19

2

Somehow the table ‘works’ has already been created in that database.
Log into mysql from the command line or however else you interact
directly with the database and drop that table manually (drop table
works;). Then you can recreate it using your migration.

3

Won’t that cause all my data to be lost though?

So do you suggest maybe me exporting my whole database, then inserting
it after doing a db:migrate?

4

Are migrations really that important? My migrations obviously are
really messed up, yet my application works fine! Will it effect me
when I try to deploy my app, will the effect me then?

Thanks!!

5

On Fri, May 23, 2008 at 8:55 PM, Garrett B. [email protected]
wrote:

Won’t that cause all my data to be lost though?

So do you suggest maybe me exporting my whole database, then inserting
it after doing a db:migrate?

If you already have the table works in your database, why did you
create a migration file to recreate it? I had assumed that you had a
table ‘works’ as a side affect of an error in a migration. If you
already have ‘works’ and you want what you have, then don’t have a
migration that creates the table. Was the migration created when you
ran ‘script/generate scaffold’? If so, you want the code that was
created but NOT the migration. For now, just delete the migration
file. In future, I am pretty sure there is a flag you can pass to
script/generate to tell it not to create the migration file.

6

On Fri, May 23, 2008 at 9:17 PM, Garrett B. [email protected]
wrote:

Are migrations really that important? My migrations obviously are
really messed up, yet my application works fine! Will it effect me
when I try to deploy my app, will the effect me then?

Migrations are an easy way to recreate a database that works with your
application. If you have another way to create a valid database (for
example migrating the data using mysqldump), then migrations are not
important.

However, I would, if I were you, spend some time getting your
migrations straightened out. One way to do that without disrupting
your working development database is to run them forwards and
backwards in a disposable database (for example your test database)
until they run without error and reproduce the structure you currently
have. Hint: “rake db:schema:dump” on your development database and
then on the play database. When the two schema.rb files match, your
migrations will reproduce the structure of your dev database.

7

I would like to echo Cynthia’s comments. Migrations are important
because they make your life a lot easier when it comes to creating and
updating your tables.

If you’ve got an existing database, look at the following page:
http://www.ruby-forum.com/topic/134848

Definitely take the time to pick up migrations. It’s simple once you
get the hang of it. It will also make your application portable…
meaning that if you decide to switch databases, you won’t have to
recreate your database. ActiveRecord will do that for you.

8

That forum topic fixed it! Thanks a bunch!

9

No problemo!