Migration numbering should be reviewed, timestamp based maybe?

[jeroenbourgois]

The problem is very simple to explain. When I am working on a branch and create some migrations, they get numbered. Assume we have a blank projects and on my branch I add the following:

001_create_users
002_create_posts
003_rename_field_name_to_username_in_users
004_create_comments

In the meanwhile, another colleague is working on the master (or dev) branch and also creating the following migrations:

001_create_userposts
002_create_images

When I merge my branch onto the master and then run the migrations from the master, every 'number' inside the name get's executed once. Our workaround for now is renaming the migrations after merging so each number is unique, but this is very tedious.

Is there another way? Rails uses timestamp bases migration names which (almost) never collide, would that not be a better approach?

/cc @pierot

[WanWizard]

You can timestamp migrations if you want, or use whatever organisation scheme. It is not required that migrations start with a sequence number. Just use 201301291414_my_migration.php.

Point remains that they will run per migrations directory, they are not collected and then sorted (which is rather pointless given the different ways you can choose to run migrations).

[jeroenbourgois]

But when you generate the migration through oil, there is not option or config to set the scheme to be used? For instance with the timestamp like you propose.

[WanWizard]

No, oil doesn't have that option, that would require a manual rename.

Oil needs a complete overhaul for v2.0, so it's a bit low prio at the moment. But you can always send a PR that would introduce a commandline option (like for example --migration=timestamp).

[hackoh]

@WanWizard
I have a bit of a question.
What do config/migrations.php mean for?

[WanWizard]

To keep track of the installed migrations.

The reason there is both a config file and a table is to allow partial migrations on deployment. For example, your source contains migrations 001-020, production is migrated to 010. If after deployment you would run an "oil r migrate --all" it would run 011-020, and sync the config file and the table.

But you could also deploy a config file that contains 001-018, so that when you run "oil r migrate::current --all", it would migratie up until 018, and not do 019 and 020. Hardly nobody uses this though, so it is probably going to disappear in 2.0...

[hackoh]

@WanWizard
I see. thanks!