I’m curious about having the ability to “roll up” a ton of migrations into a schema, and then making more migrations after that point. Designing a medium to large system would generate possibly thousands of small migrations over time, and I don’t want the directory polluted with a thousand migration files (and have to run a thousand migration files to spin up a new environment).
I was wondering if anyone had thoughts or feedback on this?
If I’m working on a feature branch that had multiple migrations on the same table, I’d consider rolling them up into a single migration as part of the cleanup before merging into master.
Once things have reached master, then I think it’s really dependent on your deploy/release strategy.
If it’s a repo where people could need to update from any point in time to any other point in time, it may be necessary to keep all the small migrations.
If you’re not releasing patches that have migrations, you could roll up migrations used in each version, as the only time they would be run would be when a new version is used.
If your data is never going to persist for very long - say some sort of caching system that is automatically rebuilt - then forcing a database reset + migrations could become part of your standard deploy process.
Another point to consider is your backup+restore process. If your database backups are never older than 90 days, then any migrations older than that point could be combined if you’re sure you’ll never need to run against an older data set.
© Copyright Elixir Forum | Terms | Privacy & Cookies
