4

I'm updating a Rails 1.2.3 app to 3.2.1.

I'm trying to figure out how I can update the migration structure to be compatible with the latest version of Rails, so that, ideally, you can just run rake db:migrate when setting up the app. Currently, I have solved this by just doing rake db:migrate:up VERSION=[version_number] of whatever migration I need to run. If I just run rake db:migrate, it tries to rerun all of the migrations from the beginning and it stops (since those migrations have already been run in the db dump I have).

Migrations in the app look like this 001_add_some_model.rb, 002_add_some_other_model.rb instead of 20120209182512_add_some_model.rb.

Does anyone have any experience with this? How can I fix this?

Improve this question
7
  • 6
    Wow from 1.2.3 to 3.2.1. Good luck... Commented Feb 10, 2012 at 14:35
  • @lucapette Thanks! It's pretty much done, I just want to make running migrations more natural. Commented Feb 10, 2012 at 14:38
  • the solution I've seen quite often is "dropping migration and create a new one as a starting point" Commented Feb 10, 2012 at 14:39
  • @lucapette Drop all migrations and re-create them? Commented Feb 10, 2012 at 14:51
  • See github.com/spree/spree/blob/master/core/db/migrate/… it's exactly what I was talking about. It's a good reference project too :) Commented Feb 10, 2012 at 14:53

3 Answers 3

Reset to default
6

I think you should restart your migrations, drop all the migration you have and create a new migration with definitions of your current models. See this migration as a starting example.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

2

It is not recommended to run all migrations to set up a new database even in an up-to-date Rails 3 app. This is explained in db/schema.rb:

Note that this schema.rb definition is the authoritative source for your database schema. If you need to create the application database on another system, you should be using db:schema:load, not running all the migrations from scratch. The latter is a flawed and unsustainable approach (the more migrations you'll amass, the slower it'll run and the greater likelihood for issues).

Improve this answer

Comments

0

Instead of what had been suggested, I would create new migrations from scratch. Start you all your models at the current state and create new migrations for each of them, this way you could still use the power of the migrations later, like adding a column to a table or change a column type.

If you create a singe migration for all your models, like has been suggested you'll loose the model track in migrations name.

This is just another way to do it and reflects my own vision.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.