Is There a Ruby Database Migration Gem, That Helps You Move Content from an Old Structure to a New Structure

Is there a Ruby database migration gem, that helps you move content from an old structure to a new structure?

I've begun working on this.

If anyone would like to give tips on a better/more idiomatic, or more efficient implementation, please let me know.

http://github.com/btelles/legacy_migrations

edit:

I now have this exact syntax working on the above github repository... plan to add a few rake tasks for mapping the old structure to new ActiveRecord classes, and more transforms...in case anyone's interested.

It's also on gemcutter/rubygems: gem install legacy_migrations

How do I move a column (with contents) to another table in a Rails migration?

I ended up using this migration (tested, it works, and rolls back successfully):

class AddPropertyToUser < ActiveRecord::Migration
  def self.up
    add_column :users, :someprop, :string
    execute "UPDATE users u, profiles p SET u.someprop = p.someprop WHERE u.id = p.user_id"
    remove_column :profiles, :someprop
  end

  def self.down
    add_column :profiles, :someprop, :string
    execute "UPDATE profiles p, users u SET p.someprop = u.someprop WHERE p.user_id = u.id"
    remove_column :users, :someprop
  end
end

I like it because it avoids the row-by-row updates on a large database.

Is it a good idea to purge old Rails migration files?

They are relatively small, so I would choose to keep them, just for the record.

You should write your migrations without referencing models, or other parts of application, because they'll come back to you haunting ;)

Check out these guidelines:

http://guides.rubyonrails.org/migrations.html#using-models-in-your-migrations

Is there a gem that allows you to create migrations based on changes to a model?

No, and this is a bit backwards to how Rails expects to work.

One issue is that you'll often have attr_accessible properties that aren't supposed to be persisted, for example, a password field used to generate the persisted, encrypted password.

Migration with double db files on ruby on rails

Just to clarify, these two files are database migration files and meant to change the database structure. Here you can check out the official guides for further details on how they work.

The problem is that you are trying to do the same modifications to the DB two times. The first time the devise_create_users migration is run, it creates a users table with columns email, encrypted_password and so on. Then the second file, the add_devise_to_users is run that tries to modify the users table by adding the same columns (email, encrypted_password, etc.). The former is for adding devise to a new project where no user model exists yet, while the latter is for adding devise to an already existing user.

To solve this issue you just have to remove the second migration file add_devise_to_users as it is not necessary in your case.

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

Keep old user with new Ruby on Rails database

So you have several options available to you. If you are going to be keeping the User table structure the same then you can export a sql dump of the user table and just import it back into the new database and it should work like nothing ever happened.

see this answer How to take backup of a single table in a MySQL database?

You could also export the contents to a CSV then write a script to import the user information back into the database.

I would go with the database dump solution though, also most importantly BACKUP YOUR ENTIRE DATABASE BEFORE HAND.

---

Related Topics