Running only a single migration?

[mxstbr]

Maybe this is already possible, just not documented, but it'd be awesome to be able to run a single migration based on the name it was created as:

# Only run seed migration up
rethinkdb-migrate up seed

# Only run staging migration down
rethinkdb-migrate down staging

Even better if that had glob support:

# Run all migrations starting with "seed" up
rethinkdb-migrate up 'seed*'

[vinicius0026]

@mxstbr It is still not possible to run a single migration by name. I'll add this issue to 1.1 milestone for now, but I think this could cause some problems when a migration depends on some previously run migration.
When I have the time to think this through and make some tests I'll comment on this issue again.

[jmodjeski]

The ability to run migrations to would satisfy my needs.

rethinkdb-migrate up seed would run all un-executed migrations up to and including 'seed'.
rethinkdb-migrate down staging would run all executed migrations down to and including 'staging'.

[lirantal]

but what does 'seed' and 'staging' mean? migrations are just files in a directory, there is no other metadata associated with them.

[jmodjeski]

@lirantal As for the meta-data. When the files are created they are prefixed with a timestamp to show the order in which they should execute. (at least this is my assumption)

In retrospect, my comment above probably should have been in #19. 🤔

[lirantal]

@jmodjeski so seed and staging are just examples of migration files, right?
And you wish there was a way to run just one of them (up or down), right? or did you actually refer to also include a feature that will allow you to run migrations by their simple name? (that might introduce issues when you have duplicate names which are preceded by unique timestamps, so which would the tool chooses)

[gristow]

Looking at Laravel, we might follow their lead and use a --steps=2 option for this. Given that we're already storing the timestamp of the migration in the _migrations table, this should not be terribly hard to implement.

A quick glance at the source code makes me think all that's needed is to:

• allow a --steps option to be a number for rethinkdb-migrate down
• change a few lines in migrate.js's migrateDown function as below:

function migrateDown (options) {
  return getExecutedMigrations(options)
    .then(migrations => options.steps ? migrations.slice(0, options.steps) : migrations)
    .then(migrations => runMigrations('down', migrations, options))
    .then(migrations => clearMigrationsTable(migrations, options))
    .then(emit('info', options.steps ? `Cleared ${options.steps} migrations from table.` : 'Cleared migrations table'))
    .then(() => options)
}

From my perspective having the default behavior of down be to rollback all migrations is a bit nerve racking (visions of someone accidentally running it on production and dropping all their tables). I'd frankly prefer there be a confirmation prompt, "Do you really want to rollback all migrations?" or a --force required. But: just my $0.02.

[vinicius0026]

Hey @gristow, I agree that having the default behavior as rolling back all migrations is not ideal.

I think the default behavior, not only for the Laravel migration API you cited but for other migration tools is to batch migrations for rollback, so if you created 2 new migrations and then migrated up those two in a single migrate up operation, when you roll back changes those two migrations would be undone. I think this should be target behavior if we are to change how rollback is done, but that would require more changes that what you proposed. The step option is more straightforward, of course.

@lirantal what do you think? I can start working on this, which would require a major release, but I don't have much time available to work on this, so it might not get done too soon. Of course, PRs are accepted and appreciated.

[gristow]

I can certainly do a PR for implementing rethinkdb-migrate down --steps=[n] if that would be helpful. That probably wouldn't require a major release, as it's just an option, yes?

[lirantal]

Agree with @gristow about the default not being rolling back everything as that can lead to disastrous state and instead requiring an actual --step extra argument to specify the count.

In general, there are two requirements in this issue:

1. support --step parameter
2. allow running migrations based on their name

@gristow let the PR party begin ;-)

[gristow]

Great, PR for --step argument on rethinkdb-migrate down to follow shortly.

For symmetry, should I add --step to rethinkdb-migrate up also?

[lirantal]

definitely, thanks!

[vinicius0026]

v1.4.0 released with --step support. Thanks to @gristow!