Moreover, Django already has facilities for compacting migration files together: squashing.

https://docs.djangoproject.com/en/1.9/topics/migrations/#mig...

I agree but I also have migrations that don't correspond to any release of the product. You need to run a migration to update your database so you can test your changes. A single product release might contain hundreds of migration files; maybe some that simply undo the affect of some previous migration. The pain of that is real but your point is valid.

I like this product but I agree that it doesn't solve all migration issues. I do think we need better migration tools.

In theory yes, but I've barely looked at those old migration files even the latest one. Barely rollback, just patch with a new one. Some people say a rollback is just another migration "up"

In many (most?) cases people have a single production environment.

If you have multiple versions in the wild to support, there's nothing stopping you from supporting multiple upgrade paths, or even continuing to chain migration files, if you want to.

Moving data about is always going to be a manual process. This approach just helps you test it better.

You just got done telling me that migrations are bad, but also the solution to some non-trivial deployment scenario is to just continue using migrations?

> Moving data about is always going to be a manual process.

No, it's not always.

Did you even read it? No idea where you got "migrations are bad" from.

If moving data around within a migration isn't always a manual process, please show me the tool which automatically generates the correct statements.

I don't believe a tool can always generate the correct statements. But I do believe those same statements can be used on all deployments, which I consider automation.

What about apps running on users’ devices, with their own internal databases for local storage?

When a user on random old version finally updates their app to latest, that latest code better be able to handle a migration correctly.

I don't buy this at all. It may be true for projects with only a single developer, but consider environments with a larger team.

First, every developer has a development environment. If someone goes on holiday for a few weeks they will come back to a personal environment that's likely several steps behind everyone else.

Smart engineering orgs have one or (hopefully) more QA environments which differ from production by design - they're where you preview and test upcoming features that may involve schema changes.

At a certain scale individual teams may have their own dedicated QA environments, for testing in-development features without disrupting the work of other teams.

Then there are environments for running integration tests, hooking up to CI systems, load testing etc.

There may be only one production environment but there could be dozens or even hundreds of other environments that need to be able to reliably apply migrations up to a specific point.

The Django approach to migrations handles this really well.

? None of those are production environments.

They're "production" in as much as they need to work. They still need to have migrations applied to them in an automated and repeatable way.

"An environment that needs to work" is not what "production environment" means.

I would say this is a pretty limited view. If you're working on a large team with many non production environments, this style is far more cumbersome than the upgrade chain method.

If we're talking about deployed sqlite dbs running on client machines, expecting an upgrade to be a manual process is simply not acceptable.

What makes it more cumbersome?

If I'm understanding correctly, the suggestion is to run the migration by hand and handle issues as they arise. Not nearly as nice as an automated migration.

The talk is more about creation migration scripts than deploying them, but definitely not suggesting doing anything by hand. The idea is to ensure correctness so you can automate the deployments with confidence.

> In many (most?) cases people have a single production environment.

No idea why this was downvoted, because this is a key truth.

You need to be able to migrate the production database to the latest version without losing any data.

You need to be able to replace any non-production database with the same schema as production. Ideally, with a (sanitised, subsetted, etc) copy of its data.

You don't need to be able to do anything else.

You're only thinking about SaaSy things there.

What about on-premises or just open-source software, where you any number of any version of your software may be installed around the universe, and those users need to upgrade to a newer version?

See my comment here about organizations with many engineers and teams: https://news.ycombinator.com/item?id=19289778

Backups...