Interest for migration batches?

[Ocramius]

Feature Request

Q	A
New Feature	yes
RFC	yes
BC Break	no

Disclaimer: I don't like rollbacks, and I'm a proponent of fail-forward strategies, but this feature comes out of needs of a third party asking me to put it in cleaner words.

Summary

In the context of a deployment, multiple DB migrations may be executed in a single migrations:migrate.

Let's assume we have these migrations defined over time

• Version111AddUniqueIndexToUsersTable
• Version222AddSearchIndexToUsersTable
• Version333AddUserActiveFlag

Let's say that we have these deployments happening, each running zero or more migrations:

• deployment 1
  • Version111AddUniqueIndexToUsersTable
• deployment 2
  • Version222AddSearchIndexToUsersTable
  • Version333AddUserActiveFlag

If we want to roll back from deployment 2 to deployment 1, a deployment tool would need to know that it needs to migrate to Version111AddUniqueIndexToUsersTable.

This means that the person or automation triggering the migration towards Version111AddUniqueIndexToUsersTable needs some contextual information on which deployments happened previously.

I'm wondering if there's interest in grouping executed migrations by batch, allowing to therefore do rollbacks like --prev-batch (rather than --prev).

[Ocramius]

/cc @goetas for feedback: this could be implemented by @Roave, given interest.

[stof]

Given that the table storing executed migrations stores the timestamp when migrations have been executed, you can already identify which versions have been executed later than the deployment 1 based on it. Do we actually need a new concept of batches (that won't have any benefits except for rollbacks) ?

[Ocramius]

Right, that's why I'm asking.

Apparently, Laravel implemented migration tracking of "batches", which is kinda this feature.

While timestamps allow for introspection, they don't really allow for automation, do they? 🤔

[goetas]

I personally do not like the concept of reverting migrations as well... but lets discuss it and see what it comes out it it.

I think that timestamps are ok but do not allow to do much.

What about something as this:

• We could add a new column deployment to the migrations table, that can be any user provided string and allow the user to pass the string when running migrations:migrate. That could be an useful feature even now that tells you in which deployment a migration was run.
• We could later add a --filter option to migrations:list to filter the list by "deployment" id... that used in the same context as above.

But this two feature will allow us now to use migrations:migrate VERSION to revert a migration using the previous command results.

This are "generic" features but might allow you to handle batch reverts... as example to revert 2-3 deployments backward.

I do not like --prev-batch because it might not be obvious how many migrations do you want to revert back.

[Ocramius]

@goetas as long as a rollback can somehow be automated, this seems fine to me: we could implement a dedicated flag for it in a PR, and then decide to either rename or discard it.

[goetas]

In the last two years the time i could invest in open source has been very limited. I might be able to review the code if anything proposed here gets published, but sadly can't do more :(

[Ocramius]

@goetas that is fine: I'm trying to throw paid developers at this problem anyway :)

Same situation for me, BTW.