Search code examples
flaskflask-sqlalchemydatabase-migrationalembicflask-migrate

Is it ok to delete old Flask-Migrate migrations?


I have a Flask app that uses Flask-SQLAlchemy and Flask-Migrate for database management. I currently have ~60 migrations.

Recently I refactored a part of my app, removing significant chunks of code in the process. Some very old migrations utilized that code, and now when I try to run flask db ... commands, I get errors, because the affected migrations cannot import that code. These migrations are for a version of my app that I never intend to go back to, so it seems like I should just delete them. I didn't see any references in the docs about pruning or maintaining migration history.

Will deleting old migrations cause any repercussions in the future? To reiterate, I do not expect to ever go back to those migrations.

I assume I can just pick a point to be the new "beginning of history" and set its down_revision to None. In that case, should I keep the old migrations for any reason, or delete the files entirely?

I suppose an alternative would be to just comment out the failing imports (and their uses) within those old migrations; since I never intend to downgrade to them it doesn't matter if they work. But that seems like a recipe for confusion.

Thanks!


Solution

  • A frequent mistake that I see people make is to include code from the application in migrations. This is a very bad idea, because when the application changes the migration starts to fail. You should write your migrations as independent scripts. If you need something from the application, you should make a copy of it in the migration script instead of importing it.

    Now about your question. Even if you are 100% sure that you will never need to downgrade that far back into your migration history, you should consider if you will ever need to regenerate your database from migrations, because in that case you will need those old migrations to be in working order.

    In my opinion the best option is to downgrade as far back as you think you will need, and generate a new initial migration at that point, with everything in it. This new initial migration will take the place of all the old ones, which then can be safely deleted.