Add support for sequential numbering of migrations

[przemyslaw-dobrowolski-cl]

When two or more developers decide to create a new migration at the same revision in a project, the order of migration is non-deterministic (according to the moment when they create migration template).
This problem can be resolved by extending goose with an option to create sequential migrations (i.e create-next) which always determine the next sequence number as the most recent existing migration version plus one. With this procedure, a possible race in migrations versioning will be resolved by CI or repository because a migration with the target version may already exist.

[joelpresence]

@przemyslaw-dobrowolski-cl I'm just starting to use goose today, but doesn't goose already add a timestamp to migration filenames and execute migrations in order of timestamp?

$ goose create AddSomeColumns
$ goose: created db/migrations/20130106093224_AddSomeColumns.go

This is how Ruby on Rails also does it.

Does that not work?

[przemyslaw-dobrowolski-cl]

Hi @joelpresence ,
that's the default behaviour of goose - to add timestamps as 'version' numbers. What this commit changes is to add an option to create migrations with sequential numbers like: 1_first_migration.sql, 2_second_migration.sql. This way, if two developers create a migration at the same time, they will both call the migration with the same version number. Then, goose will fail to read both migrations and the developers will need to resolve their conflict safely (some migrations may require strict ordering).

[nkovacs]

The order of the migrations is deterministic, it is determined by the timestamp (unless they happen to create both migrations at the exact same time, but then you'll get an error).

When the second developer merges or rebases their code (after the first developer has already pushed their new migration), they have to check that the merged code still works. Checking the migrations is part of that. Your CI should also create an empty database, run all the migrations, then run the tests. If the migrations conflict, that should catch it.

I don't think this solution is a good idea. What happens if one developer uses create, and the other uses create-next?

[VojtechVitek]

@nkovacs I agree. We don't use timestamps here at Pressly. Instead, we use numbers like 100000307_drop_some_table.sql and we bump the migration version by hand, before each merge.

Travis fails when we have any conflicting migrations and won't allow us to merge.

But I wish there was some automation for renaming the conflicting migrations.

[VojtechVitek]

Fixed in #50