Remove dependency on version number

[deepwell]

I think meteor-migrations could be significantly improved by removing the dependency on having a version number in each migration. Having a fixed version number makes migrations inflexible when working with a team.

For example, the case where you have a team of 3 people working on a product and the current migration is version 1 (or base). They all are working on new features that require database schema changes so they all make a new migration in their own branch and increment the version to 2. This breaks down when all the work is merged to master because the versions have to be re-ordered.

Ideally, this migration plugin would keep track of what migrations have already run (eg: by file name or another unique version name) and only run the migrations that have not executed yet (ie. keep a list of all successfully authenticated migrations). This solves the problem above and allows long lived feature branch to be merged in without change even if new migrations were created and added to master after the feature branch was created.

[zol]

The package was written like this originally but there is a fatal flaw. It’s pretty common that migration order is important as most of the time schema changes are not independent of each other. The versioning ensures that you’re forced to specify the order in which migrations run - without it the order is un-deterministic. Migrations should not be treated lightly, especially when working in a larger team. I would say it’s the job of the integration manager to ensure migrations are applied sanely. The versioning forces you to deal with this as a merge conflict rather than risking having the migrations applied out of order with no warning/feedback.

If you really wanted to hack your way around it just have members of your team apply a unique tag to the version, for instance ‘2bob’, then if Jane commits version ‘2jane’, they won’t clobber each other and will both be applied in whatever order the equality check applies.

On Friday, February 28, 2014 at 3:21 PM, deepwell wrote:

I think meteor-migrations could be significantly improved by removing the dependency on having a version number in each migration. Having a fixed version number makes migrations inflexible when working with a team. For example, the case where you have a team of 3 people working on a product and the current migration is version 1 (or base). They all are working on new features that require database schema changes so they all make a new migration in their own branch and increment the version to 2. This breaks down when all the work is merged to master because the versions have to be re-ordered. Ideally, this migration plugin would keep track of what migrations have already run (eg: by file name or another unique version name) and only run the migrations that have not executed yet (ie. keep a list of all successfully authenticated migrations). This solves the problem above and allows long lived feature branch to be merged in without change even if new migrations were created and added to master after the feature branch was created.

— Reply to this email directly or view it on GitHub (https://github.com/percolatestudio/meteor-migrations/issues/6).

[MaerF0x0]

Can version numbers be sparse? If no, then one could simply put in a unix timestamp and the version will be run in the order they were started by the developer. Potentially could still have side effects, but it (probabilistically) solves the version number collisions.

[zol]

Yep, version numbers can be sparse so you're free to use whatever scheme you like.

[DominikGuzei]

Unix timestamps work great for migration versioning, collisions are very unlikely ;-) I think rails also uses some kind of timestamp for that purpose. Although it is more convenient because they have generators for all that boring stuff.

[zol]

You’re free to use whatever ordered versioning scheme you like. Unlike Rails, our migration definitions are created at runtime so the onus is on the developer to choose versions for their migrations. To try to automatically create migration versions (like Rails) wouldn’t be strait forward in a Meteor app and frankly the contortions aren’t worth it.