Immutable database migrations

[DivineOmega]

What you would like to change/add

Laravel documentation defines database migrations as follows.

Migrations are like version control for your database

Just as we do not modify git commit history, I would like to propose we officially adopt the best practice of not modifying existing database migrations once they are in a mainline branch.

A mainline branch is defined here as master, staging or production.

Why you would like to change/add this

Just as we do with our code repositories, version controlled systems should not have their histories modified apart from in exceptional circumstances. Therefore, once a PR is accepted into a mainline branch that others will be using, we should avoid making modifications to existing migrations and inconveniencing our fellow developers.

There is no harm is having a larger number of migration files. In fact, it can be useful to see the evolutionary of a tables structure to see why and when certain fields were added/removed/changed in associated with related feature development.

Concerns over this change meaning database migration files can not be used as a reference for table structure makes sense, but are not in keeping with how migrations should be used. Table structure should always be referenced from within a database schema browser.

Checklist

• I have checked that this is not a duplicate issue.

Sources

• Introduction to Database Migrations - Laravel Documentation

[robmilward]

I completely agree in principle, however feel that during the initial stages of development of a project (i.e. times when the schema is most unstable) the ability to go back and refine the migrations in place is far more beneficial than anything that would be gained by rigidly following this rule. It would in my opinion start introducing unneeded complexity before it's an acceptable (to me) tradeoff for migration stability.

Would you make an exception for times where you're working alone on a project? Or times when the schema has changed so drastically from one moment to the next it'd be easier to drop a table than modify it? Or when you decide to extract 5/7 columns from one table into another very early on (this happened recently)?

IMO, the point at which migrations need to be stable is when there is data that needs to be protected. This could, for instance, happen once the project reaches a customer facing staging branch or production. Once one of those milestones has been reached, I'm 100% with you.

Thoughts?

[robmilward]

Just as we do not modify git commit history

Also bear in mind I love to rebase && force-push 😂

[DivineOmega]

I completely agree in principle, however feel that during the initial stages of development of a project (i.e. times when the schema is most unstable) the ability to go back and refine the migrations in place is far more beneficial than anything that would be gained by rigidly following this rule. It would in my opinion start introducing unneeded complexity before it's an acceptable (to me) tradeoff for migration stability.

In an ideal world, the client requirements would have been solidified, analysed and an appropriate database schema would defined before development starts, making this a non-issue.

However, as we can tell from the fact 30p Freddos exist (!), we do not live in an ideal world. 🙂

So, I'd have to agree with you, that this rule can be bent somewhat during the initial database schema creation where there is very little or no code relying upon it.

Would you make an exception for times where you're working alone on a project? Or times when the schema has changed so drastically from one moment to the next it'd be easier to drop a table than modify it? Or when you decide to extract 5/7 columns from one table into another very early on (this happened recently)?

While working on a project alone or with complete project team agreement, I feel that to a degree anything goes. However, once other developers are in play and/or the project is made client facing, these technologies repo guideline should be in effect.

IMO, the point at which migrations need to be stable is when there is data that needs to be protected. This could, for instance, happen once the project reaches a customer facing staging branch or production. Once one of those milestones has been reached, I'm 100% with you.

Generally agreed, though I believe the milestones you mention should ideally be earlier on - as early as can be convenient. Significant restructuring of the database and table schemas is a symptom of other issues, such an incorrect requirement specification or poor database design.

Thoughts?

In conclusion, I'd agree with this guideline being flexible very early in development (perhaps the first 1-2 sprints), but becoming less flexible very quickly beyond this. Once it reaches staging/production or other developers are introduced, this should be rigidly enforced.

[robmilward]

Then I think we're on the same page! :) 👍 👍