Migration file id clash across branches

[vighnesh1987]

I'm running into some trouble and am not sure what the best solution for it is.
Here's the scenario:

1. Let's say developer A branches off staging to work on feature1
2. Developer B branches off staging to work on feature2
3. Current number of migrations on staging are 3
4. Developer A creates a migration file - which gets id 4 ie. named 0004_xxx.(up|down).sql
5. Developer B creates a migration file too which gets id 4 too
6. Developer A's pull request gets merged first.
7. Developer B's pull request gets merged second.
8. This means staging now has 2 migration file sets (up + down) with the same prefix.
9. Next time someone pulls down staging and runs the migrate command, only one of the 2 migration up files with prefix 0004 gets run.

Simple fix seems to be to use timestamps as prefixes. What's the best way of setting that up?

[cihangir]

if i were the repo maintainer, i wouldn't care about finding a solution to this problem, to me this is purely SDLC/user problem. Timestamps can also create problems depending on their merge order to master.

[mattes]

@johnweldon added a fix to this. It will through an error if there are two files with the same id.

[gravis]

FYI, we're going to propose a PR soon for this. We just started to use the lib, and already have issues with version collision. Ruby on Rails did this change a few years ago for the same reason. Sequential versions simply don't work with large teams...

[johnweldon]

I've used Date+Time based migrations before which usually works, but the problem is bigger than just the naming of the migration. If you have two people doing a database migration at the same time you still have to manually inspect the two migrations to make sure they're compatible. Naming isn't the issue, and having the collision helps bring attention to the potential for conflict.