4 ms·

Two developers pull code with migration version 4. Each writes a new feature involving a migration. Both get the number 5, which then collides when they both ch

Two developers pull code with migration version 4. Each writes a new feature involving a migration. Both get the number 5, which then collides when they both check in. But it doesn't collide at the source level, so you only find out when the db doesn't work right. This was a big pain in the ass in Rails until they fixed it.

kiddo 16y ago
Why don't they collide at the source level? I'm assuming the db updates get checked into your central source code repo. Wouldn't the collision happen at that time? What happens when developers create branches and use time stamps? Developer A working on trunk might check in db updates at 4pm and 5pm. Developer B working on a branch checks db updates into his branch at 4:30pm and 5:30pm. When working on the branch his db updates don't affect the "trunk" db. As soon as he merges does his 4:30pm update get run on the "trunk" db, or is it skipped over because the 5pm db update already ran, and only the 5:30pm change gets run? Where I come from we use int values for our db update script names. When I merge from a branch I renumber my db update script file names starting at the tip int value +1 of the trunk db update. fyi - I'm not coming from a Ruby/Rails perspective, if that matters.
- rahoulb 16y ago
  There's a table listing the migrations that have already been run on the database. The list of migrations in source control are compared against the list in the database, the outstanding ones sorted into timestamp order and then run. So if the two branches are separate there should be no issue - all my changes get run in order, irrespective of what the other developers have been doing.
- kemiller 16y ago
  They don't collide because the file names include more than just the number. And yes, manually renumbering is exactly what you'd have to do. Timestamps obviate that. Theoretically, you can still have collisions (two migrations alter the same column, eg) or violated prereqs this way, so some communication is still required, but not to the degree before.

kiddo 16y ago

Why don't they collide at the source level? I'm assuming the db updates get checked into your central source code repo. Wouldn't the collision happen at that time? What happens when developers create branches and use time stamps? Developer A working on trunk might check in db updates at 4pm and 5pm. Developer B working on a branch checks db updates into his branch at 4:30pm and 5:30pm. When working on the branch his db updates don't affect the "trunk" db. As soon as he merges does his 4:30pm update get run on the "trunk" db, or is it skipped over because the 5pm db update already ran, and only the 5:30pm change gets run? Where I come from we use int values for our db update script names. When I merge from a branch I renumber my db update script file names starting at the tip int value +1 of the trunk db update. fyi - I'm not coming from a Ruby/Rails perspective, if that matters.

rahoulb 16y ago
There's a table listing the migrations that have already been run on the database. The list of migrations in source control are compared against the list in the database, the outstanding ones sorted into timestamp order and then run. So if the two branches are separate there should be no issue - all my changes get run in order, irrespective of what the other developers have been doing.
kemiller 16y ago
They don't collide because the file names include more than just the number. And yes, manually renumbering is exactly what you'd have to do. Timestamps obviate that. Theoretically, you can still have collisions (two migrations alter the same column, eg) or violated prereqs this way, so some communication is still required, but not to the degree before.