[suggestion] What to do when no. of migrations gets very large

[derekdreery]

I've used a framework before written in PHP that handles migrations in a slightly different way. In that system, you must keep an install.sql file up to date with the latest version of the db, and then add extra migrations with db_version to migrate. This has the advantage that if you have many, many migrations (this project is c. 10 years old - 1000s of migrations) you get a quicker initial install for new instances of the system. Is this an issue that needs to be thought about, or should applying lots of migrations on initialization never take too long?

Just to give an example of how this works, the migration file is like the following:

{
    "201501010030": "CREATE TABLE test ( .......",
    "201501021123": "ALTER TABLE test ADD ....."
}

and the install file is just flat sql.

[derekdreery]

Related issue - it may be useful to group migrations into year-month to stop the folder getting too full.

[sgrif]

Most backends provide some sort of a schema dump tool, which I think is the main path forward for something like that. I could see us potentially hooking into that with Diesel setup

[sgrif]

Going to close this, since it's not immediately actionable. I'm happy to consider a feature for this if an issue were to be opened with a concrete proposal on what the API for this would look like, and exactly what it would do.