Ruby-on-rails – Why is rake throwing this Rails migration error

migrationrakeruby-on-rails

I have two machines… a development machine and a production machine. When I first brought my rails app onto the production server, I had no problem. I simply imported schema.rb by running rake db:schema:load RAILS_ENV=production. All was well.

So, then on my development machine, I made some more changes and another migration, and then copy the new application over to the production machine. I then tried to update the database by running rake db:migrate RAILS_ENV=production. I get the following error:
"There is already an object named 'schema_migrations' in the database."

I'm thinking to myself, ya no kidding Rake… you created it! I ran trace on rake and it seems as if rake thinks it's the first time it's ever ran. However, by analyzing my 'schema_migrations' table on my development machine and my production machine you can see that there is a difference of one migration, namely the one that I want to migrate.

I have also tried to explicitly define the version number, but that doesn't work either.

Any ideas on how I can bring my production server up to date?

Update:

Let me start off by saying that I can't just 'drop' the database. It's a production server with a little over 100k records already in it. What happens if a similar problem occurs in the future? Am, I to just drop the table every time a database problem occurs? It might work this time, but it doesn't seem like a practical long term solution to every database problem. I doubt the problem I'm having now is unique to me.

It sounds like the 'schema_info' table and the 'schema_migrations' table are the same. In my setup, I only have 'schema_migrations'. As stated previously, the difference between the 'schema_migrations' table on the production server and the development machine is just one record. That is, the record containing the version number of the change I want to migrate.
From the book I read, 'Simply Rails 2', it states that when first moving to a production server, instead of running rake db:migrate, one should just run rake:db:schema:load.
If it matters, I'm using Rails version 2.1.

Best Answer

This is a guess, I admit: I think that because you first ran db:schema:load instead of db:migrate in your production environment, you got the structure of your db, but not the data that migrate populates into your schema_info table. So now, when you run migrate in the production environment, there is no data in schema_info which is why migrate believes that it hasn't run yet (because it hasn't).

That said... you say that you have looked in the "schema_migrations" table, and that there is a difference of one version from dev to production... I haven't heard of that table, although I'm a few months behind on my rails version. Maybe you could try creating a "schema_info" table in the production environment, with a single "version" column, and add a row with the version that you believe your production environment to be on.

Related Solutions

Ruby-on-rails – rake db:migrate doesn’t detect new migration

You should be able to use

rake db:migrate:up

to force it to go forward, but then you risk missing interleaved migrations from other people on your team

if you run

rake db:migrate

twice, it will reapply all your migrations.

I encounter the same behavior on windows with SQLite, it might be a bug specific to such an environment.

Edit -- I found why. In the railstie database.rake task you have the following code :

desc "Migrate the database through scripts in db/migrate. Target specific version with VERSION=x. Turn off output with VERBOSE=false."
task :migrate => :environment do
  ActiveRecord::Migration.verbose = ENV["VERBOSE"] ? ENV["VERBOSE"] == "true" : true
  ActiveRecord::Migrator.migrate("db/migrate/", ENV["VERSION"] ? ENV["VERSION"].to_i : nil)
  Rake::Task["db:schema:dump"].invoke if ActiveRecord::Base.schema_format == :ruby
end

Then in my environment variables I have

echo %Version% #=> V3.5.0f

in Ruby

ENV["VERSION"] # => V3.5.0f
ENV["VERSION"].to_i #=>0 not nil !

thus the rake task calls

ActiveRecord::Migrator.migrate("db/migrate/", 0)

and in ActiveRecord::Migrator we have :

class Migrator#:nodoc:
  class << self
    def migrate(migrations_path, target_version = nil)
      case
        when target_version.nil?              then up(migrations_path, target_version)
        when current_version > target_version then down(migrations_path, target_version)
        else                                       up(migrations_path, target_version)
      end
    end

Yes, rake db:migrate VERSION=0 is the long version for rake db:migrate:down

Edit - I would go update the lighthouse bug but I the super company proxy forbids that I connect there

In the meantime you may try to unset Version before you call migrate ...

Mysql – Rolling back a failed Rails migration

Unfortunately, you must manually clean up failed migrations for MySQL. MySQL does not support transactional database definition changes.

Rails 2.2 includes transactional migrations for PostgreSQL. Rails 2.3 includes transactional migrations for SQLite.

This doesn't really help you for your problem right now, but if you have a choice of database on future projects, I recommend using one with support for transactional DDL because it makes migrations much more pleasant.

Update - this is still true in 2017, on Rails 4.2.7 and MySQL 5.7, reported by Alejandro Babio in another answer here.

Best Answer

Related Solutions

Ruby-on-rails – rake db:migrate doesn’t detect new migration

Mysql – Rolling back a failed Rails migration

Related Topic