Migrations, branches and dependencies
courtenay just sent in a new ticket for Rails Core: #6799. To summarize, his patch allows two migrations to have the same number, and migrates them in parallel. courtenay blogged about his patch as simultaneous migrations
I’ve written a patch to migration code so you can have multiple migrations with the same number. This means that these migrations can effectively be run in parallel, so long as all the migrations with that number have the IndependentMigration class.
His patch is interesting, and solves a real problem. But, his two caveats render the solution slightly too complex.
What if instead of version numbers we had migrations with timestamps ? We would need a few changes for that to be useful:
- All timestamps must be in the UTC timezone;
- The schema_info table must change (or be replaced) to have many records instead of only one.
Then, when we run the migrations, we order the migration files by name, and check if the record exists in the schema_info table. If it doesn’t, we migrate and record the time at which the migration ran.
Example
Let’s assume we are on trunk/. The following migrations already exists.
db/
migrate/
20061208111503_create_posts.rb
20061208111504_create_tags.rb
20061208111505_create_taggings.rb
The migrations table I was talking about above would look something like this:
We have another developer who was working on another branch, and he just merged back to trunk/. Let’s update:
Now that we have his code, let’s migrate and run the tests
CreateUsers was run because it’s timestamp comes before CreatePosts. CreatePosts, CreateTags and CreateTaggings weren’t run because they had already been run. Finally, CreateLinks was run because it hadn’t been run yet.
The only thing missing now is the interim world. What do we do with existing migrations ? I believe we should simply migrate all low-level migrations before we do the new ones. That should ensure all migrations are up to date, no ?
I know code speaks louder than words. Just give me a couple of hours, will you ?
October 12th, 2007 at 10:25 PM
Sounds like a great solution to me! I think you’re right, just run all numbered migrations first followed by all timestamped migrations. Migration numbering is one of the sore spots of rails because it doesn’t work well with distributed teams, so you end up having to call out ‘hey #54 is mine dont touch it’ which is rather silly.
October 12th, 2007 at 10:25 PM
I also second this approach…looking forward to seeing some code samples. Are you still pursuing this.
February 25th, 2008 at 03:54 PM
Well, you’ve had a few months, where are we at with this? if it’s anywhere near plugin-status, I have myself and another who’d be willing to contribute time to get this working. :)
February 27th, 2008 at 10:18 AM
Steven, the Enhanced Migrations plugin takes care of this. It was written by the Revolution on Rails team. Hope that helps !
July 10th, 2008 at 03:19 AM
car insurance quotes acomplia rx car insurance group health insurance real series video slots online auto insurance quotes ambien 5 mg life insurance tramadol affordable health insurance purchase propecia levitra dosage free casino games order klonopin naprosyn blackjack pokerplayer skillonline casinoguide tramadol pediatric ltc insurance buy viagra cheap cheap car insurance quote