How are Migration Scripts applied in Rails 2.1 and higher?

Question

I'm not a Rails developer (currently) so please forgive my ignorance on this.

One thing I've always liked about Rails is migrations and how it fills a need that's common across all languages and platforms. With that said, I am curious to understand what a certain scenario would result with the changes made in 2.1.

Rails 2.1 and higher, from what I can tell, made two changes to the migrations logic. The first was to use timestamp based script names when generated in order to reduce the probability of 2 developers working on the same file at the same time before adding the file to source control. So instead of 002_test.rb, it is now 20090729123456_test.rb when the script is generated.

The second item was that the Schema_Info table was replaced with the Schema_Migrations table that presented a list of migrations and not just the latest version number.

Looking through the Rails source, I noticed that it took the "current version" of the schema as the max version found in the Schema_Migration table.

Here's the scenario I'm trying to figure out:

Developer A generates a new script: 20090729120000_test.rb.

Developer B generates a new script: 20090729130000_test.rb.

Developer B migrates his script to the database first by not specifying the version number and assuming that Developer A's script isn't added yet.

What happens when Developer A adds his script and tries to migrate to the latest version since his script version (based on the time stamp) is less than the currently applied version now?

Answer 1

I'm not positive, but I believe that he would have to do a "rake db:rollback" to undo the Developer B migration, then run "rake db:migrate" to do both of them in the proper order. Of course, if two developers are working independently on tables that require no integration with one another (as this case shows, since Developer B didn't have to wait for Developer A to run his migration), developer A can simply add one to the timestamp of Developer B's migration and it will be in proper order once again.

Answer 2

The short answer is: don't worry about it.

rake db:migrate will attempt to run any migrations that are not found in the schema_migrations table. It doesn't matter if there are newer migrations that have already been run.

If B is dependent on A and must be run in that order, then you might have a problem, but that's an issue between the developers.