3 ms·
Migrations are a minor pain point for me. The libraries I've used don't support running (all) pending migrations; only those with a timestamp more recent than t
by aczerepinski 9y ago
Migrations are a minor pain point for me. The libraries I've used don't support running (all) pending migrations; only those with a timestamp more recent than the previous one. This means we have to finesse the timestamps manually as migrations get merged into the main branch and deployed to various environments. As such, the value offered by the migration library is pretty minimal compared to just remembering to pipe a .sql file directly into the database. Hopefully there's a more robust option out there that I just haven't found yet.
- grey-area 9y agoI take the approach of storing the name of any migrations run in the database in a metadata table - this means you can run them out of order, restore from a backup then run migrations not yet run etc. to test or adjust them. With multiple devs it's often the case that we want to run things out of order on production too, so ordering by time doesn't work and running manually is error-prone. Code for this here - it'd be pretty simple to put it in its own little tool or even a bash script or something, and there are surely some other tools that do something similar... This one psql only as it relies on the psql binary to load the sql, but hopefully gives you the idea. I haven't bothered developing it further to do things like run a single migration or down migrations as haven't required that so far. https://github.com/fragmenta/fragmenta/blob/master/migrate.go https://github.com/fragmenta/fragmenta/blob/master/migrate.g...