MigrateNext option: run only single next pending migration

[realkarych]

Currently, the migrate command applies all pending migrations at once. In many scenarios, required finer control to apply migrations one at a time (e.g., for testing or debugging purposes). I propose the addition of a new command, migrate-next, which will apply only the next pending migration.

So I added issue (#631) with linked implementation (#632)

[realkarych]

In our production, we use dbmate. So I cannot add integration staircase tests over dbmate. Down steps I currently control, because we have rollback option, and no option for up.

I compare schema-dumps on every staircase step. 1 — first migration, 5 — last (new) migration. Idea on the picture:

[dossy]

Related: #364

[realkarych]

@dossy I read #364 and didn’t quite understand how my feature request is related to that issue. The current problem is inconsistency between commands: there is a way to roll back exactly one migration, but no way to apply exactly one migration.

If we don’t want to move this into the scope of general commands, let’s add an optional boolean flag to the existing migrate command that would do exactly what I’m suggesting above?

[dossy]

What is an "integration staircase test" and why would you need to do such a thing?

#364 is related in that perhaps the solution isn't "make dbmate do [x]" but "don't test in a way that requires dbmate do [x]", like @amacneil's comment in that discussion:

Makes sense. I'm not sure whether you considered this, but in the past when running test suites I just drop and recreate the database once at the very start (before my test harness connects to the db), then run a command like TRUNCATE tablea, tableb, tablec CASCADE in between each test suite. It's much faster than running all the migrations for every test.

Like I commented on your PR #632, I am not qualified to decide whether your approach requires dbmate to do what you want it to, and sometimes constraints serve a useful purpose.

[realkarych]

What is an "integration staircase test" and why would you need to do such a thing?

#364 is related in that perhaps the solution isn't "make dbmate do [x]" but "don't test in a way that requires dbmate do [x]", like @amacneil's comment in that discussion:

Makes sense. I'm not sure whether you considered this, but in the past when running test suites I just drop and recreate the database once at the very start (before my test harness connects to the db), then run a command like TRUNCATE tablea, tableb, tablec CASCADE in between each test suite. It's much faster than running all the migrations for every test.

Like I commented on your PR #632, I am not qualified to decide whether your approach requires dbmate to do what you want it to, and sometimes constraints serve a useful purpose.

I need to be able to apply exactly one migration. This is valid in a significant number of cases — from the integration test example I shared earlier, to debugging a specific migration.

Using version-based migration jump doesn’t solve the problem in the general case, because I might not know (without having the full list of migrations) which migration comes before or after. For example, the migrations might be stored in a separate repository that I don’t have access to. That’s exactly why rollback exists — but there’s no command that does the inverse of a rollback. There’s simply no direct counterpart, only various hacks that depend on extra context, which may not always be available.