# Migrations get out of synch with code - ideas?

**URL:** <https://www.ruby-forum.com/t/migrations-get-out-of-synch-with-code-ideas/186165>\
**Category:** Rails\
**Created:** [April 1, 2010, 2:48pm UTC](https://www.ruby-forum.com/t/migrations-get-out-of-synch-with-code-ideas/186165 "2010-04-01T14:48:50Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![cmaxvv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/85f322/32.png) [@cmaxvv](https://www.ruby-forum.com/u/cmaxvv)\
**Post date:** [April 1, 2010, 2:48pm UTC](https://www.ruby-forum.com/t/migrations-get-out-of-synch-with-code-ideas/186165/1 "2010-04-01T14:48:50Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![cmaxvv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/85f322/32.png) [@cmaxvv](https://www.ruby-forum.com/u/cmaxvv)\
**Post date:** [April 1, 2010, 2:53pm UTC](https://www.ruby-forum.com/t/migrations-get-out-of-synch-with-code-ideas/186165/2 "2010-04-01T14:53:41Z")

</div>

On Apr 1, 1:48 pm, Max W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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

---

<div class="post-metadata">

**Author:** ![cmaxvv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/85f322/32.png) [@cmaxvv](https://www.ruby-forum.com/u/cmaxvv)\
**Post date:** [April 1, 2010, 4:03pm UTC](https://www.ruby-forum.com/t/migrations-get-out-of-synch-with-code-ideas/186165/3 "2010-04-01T16:03:40Z")

</div>

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.