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?
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.