Migrations get out of synch with code - ideas?

I just fell foul of a problem that i’ve encountered several times in the
past and never really thought of a good solution. I wonder if there’s a
solution out there for this.

I just did some refactoring, moving Quiz#subject from being a text field
in the quizzes table to being a standalone table, so that the quizzes
table now has subject_id instead of subject. A typical bit of
normalisation.

There was a chain of migrations association with this, and in those
migrations were references to methods which existed at the time that the
migration was done, but were subsequently removed. So, my local
workflow was

  • make migrations
  • run migrations
  • change code

One of my colleagues then pulls down my changes, and runs the
migrations, and they blow up because the earlier ones use methods which
were there the time that I ran the migration, but now aren’t. So, i
have to go and refactor the migrations themselves to work with the
post-migration codebase, push them up, then he pulls them down again and
runs them. I’ve fallen foul of this before when doing a deploy with
migrations as well.

Ways around it i can think of …

a) i make sure that my migrations don’t use something from the codebase
which is going to be deleted in the future. This seems difficult if not
(conceptually at least) impossible. When you’re doing a refactor you
often have to use the old system/data to configure the new data.

b) my colleague pulls down the migrations folder before pulling down any
other folders, runs the migrations, then pulls the rest. This seems to
place unreasonable expectations on him, plus even then if he pulls
multiple commits at once (ie his code is even more out of sync with the
migrations) then it can still go wrong.

c) I break the process up into seperate commits, and some sort of clever
system runs through this sequence:

  • get one commit
  • run migrations (if any)
  • repeat until up to date

This seems ideal but i’m not sure how to set it up.

Any opinions/advice anyone?

On Apr 1, 1:48 pm, Max W. [email protected] wrote:

Ways around it i can think of …

a) i make sure that my migrations don’t use something from the codebase
which is going to be deleted in the future. This seems difficult if not
(conceptually at least) impossible. When you’re doing a refactor you
often have to use the old system/data to configure the new data.

Create private copies of the classes involved in the migration ie

class ChangeQuizzes < ActiveRecord::Migration
class Quiz < ActiveRecord::Base; end

end

obviously include only what behaviour the migration actually needs.

Fred

Frederick C. wrote:

Create private copies of the classes involved in the migration ie

class ChangeQuizzes < ActiveRecord::Migration
class Quiz < ActiveRecord::Base; end

end

obviously include only what behaviour the migration actually needs.

Fred

ah, now that’s a good idea. thanks fred.