# Sequence of migration execution in 2.1

**URL:** <https://www.ruby-forum.com/t/sequence-of-migration-execution-in-2-1/144568>\
**Category:** Rails\
**Created:** [July 31, 2008, 1:37am UTC](https://www.ruby-forum.com/t/sequence-of-migration-execution-in-2-1/144568 "2008-07-31T01:37:44Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![plambert](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/9d8465/32.png) [@plambert](https://www.ruby-forum.com/u/plambert)\
**Post date:** [July 31, 2008, 1:37am UTC](https://www.ruby-forum.com/t/sequence-of-migration-execution-in-2-1/144568/1 "2008-07-31T01:37:44Z")

</div>

Our project is currently running Rails 2.0, and I am concerned about  
the use of timestamps in migration file names in Rails 2.1. We use  
migrations a lot, for both table structure changes and application  
data changes, and it can happen that the order in which the migrations  
are run matters. Developers are required to update their area to get  
the latest changes before checking in, and it frequently happens that  
a migration file needs to be renamed prior to check in. But, that is  
okay, because it means that the developer wanting to check in the  
migration will first have to make sure (by running tests) that the  
renumbered migration will still work after the other migrations have  
been run. In this way, all the developers have to run the migrations  
in the same order.

In the new migration system with timestamps, rake db:migrate just runs  
whatever migrations haven’t been run yet. If developer A checks in a  
migration, and then developer B does an update before checking in his  
migration, B will end up getting A’s migration run after his (which  
might affect the outcome of the tests) and after developer A does an  
update, A will get B’s migration run last. If the order matters, A’s  
database will not be the same as B’s, even though the areas of both  
will appear up to date.

This is not a good thing. Yes, conflicts in migration numbers are an  
annoyance, but they are an important annoyance, because they force you  
to make sure your changes are compatible with ones that are already  
checked in.

Is there a configuration option to turn this 2.1 feature off?  
–Paul

---

<div class="post-metadata">

**Author:** ![plambert](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/9d8465/32.png) [@plambert](https://www.ruby-forum.com/u/plambert)\
**Post date:** [July 31, 2008, 2:25am UTC](https://www.ruby-forum.com/t/sequence-of-migration-execution-in-2-1/144568/2 "2008-07-31T02:25:08Z")

</div>

> Is there a configuration option to turn this 2.1 feature off?  
> –Paul

config.active\_record.timestamped\_migrations = false

(I haven’t tried this; it is according to  
[http://ryandaigle.com/articles/2008/4/2/what-s-new-in-edge-rails-utc-based-migration-versioning](http://ryandaigle.com/articles/2008/4/2/what-s-new-in-edge-rails-utc-based-migration-versioning))

Not sure how common the scenario you outlined is. We’re using  
timestamped migrations with no trouble (so far) in a team of 8 or 9  
developers.

---

<div class="post-metadata">

**Author:** ![plambert](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/9d8465/32.png) [@plambert](https://www.ruby-forum.com/u/plambert)\
**Post date:** [July 31, 2008, 11:28pm UTC](https://www.ruby-forum.com/t/sequence-of-migration-execution-in-2-1/144568/3 "2008-07-31T23:28:41Z")

</div>

Thanks!

On Jul 30, 8:25 pm, Jeremy Weiskotten \<rails-mailing-l…@andreas-