Using Rails Migration on Different Database Than Standard "Production" or "Development"

Using Rails Migration on different database than standard production or development

A bit late, but I was dealing with this problem today and I came up with this custom rake task:

namespace :db do
  desc "Apply db tasks in custom databases, for example  rake db:alter[db:migrate,test-es] applies db:migrate on the database defined as test-es in databases.yml"
  task :alter, [:task,:database] => [:environment] do |t, args|
    require 'activerecord'
    puts "Applying #{args.task} on #{args.database}"
    ActiveRecord::Base.establish_connection(ActiveRecord::Base.configurations[args.database])
    Rake::Task[args.task].invoke
  end
end

Rails migrate with different databases

=================================UPDATE=================================

I find a nice article talking about it: http://www.thegreatcodeadventure.com/managing-multiple-databases-in-a-single-rails-application/

=================================UPDATE=================================

I just put establish_connection out of a migrate class.

ActiveRecord::Base.establish_connection "users_#{Rails.env}"
class AddDeviseToUsers < ActiveRecord::Migration
  def self.up

    change_table(:users) do |t|
      ## Database authenticatable
      t.string :email,              :null => false, :default => ""
      t.string :encrypted_password, :null => false, :default => ""

      ## Recoverable
      t.string   :reset_password_token
      t.datetime :reset_password_sent_at

      ## Rememberable
      t.datetime :remember_created_at

      ## Trackable
      t.integer  :sign_in_count, :default => 0, :null => false
      t.datetime :current_sign_in_at
      t.datetime :last_sign_in_at
      t.string   :current_sign_in_ip
      t.string   :last_sign_in_ip

      ## Confirmable
      # t.string   :confirmation_token
      # t.datetime :confirmed_at
      # t.datetime :confirmation_sent_at
      # t.string   :unconfirmed_email # Only if using reconfirmable

      ## Lockable
      # t.integer  :failed_attempts, :default => 0, :null => false # Only if lock strategy is :failed_attempts
      # t.string   :unlock_token # Only if unlock strategy is :email or :both
      # t.datetime :locked_at


      # Uncomment below if timestamps were not included in your original model.
      # t.timestamps
    end

    add_index :users, :email,                :unique => true
    add_index :users, :reset_password_token, :unique => true
    # add_index :users, :confirmation_token,   :unique => true
    # add_index :users, :unlock_token,         :unique => true
  end

  def self.down
    # By default, we don't want to make any assumption about how to roll back a migration when your
    # model already existed. Please edit below which fields you would like to remove in this migration.
    raise ActiveRecord::IrreversibleMigration
  end
end

why schema.rb file differently between development and production environment?

Not sure why and how this could have happened, but I'd try to rollback the production db completely first, than just load up the schema and check

to rollback the production db:

rake db:rollback RAILS_ENV=production STEP=100

to load the schema:

rake db:schema:load RAILS_ENV=production

Can Rails app and rake db:migrate use different database credentials?

You could make a new environment configuration, similar to development and production, database_admin, and use rake db:migrate RAILS_ENV=database_admin.

If you get tired of typing the extra environment information all the time, you could use the clever rake tasks here to help reduce the tedium: http://errtheblog.com/posts/31-rake-around-the-rosie

---

Related Topics