It’s time for me to tackle one of the “big ones”: database migrations. (cue dramatic music)
When you’re developing or prototyping, and not quite sure what your next schema will look like yet, it can be a major pain. Adding migrations one by one, rolling back and forth, etc. is not exactly pleasant.
The dream: I can only change a line in schema.rb, maybe run a one liner, and my local schema is up to date.
When researching the issue the other day, I came across this provocatively-titled talk from djrobstep: Your migrations are bad, and you should feel bad, and its associated library, migra, a “comparison tool for Postgres”. In short, the tool diffs the two schemas and automatically infers a migration between the two.
I think this is an approach on which we could build upon.
Now, I’m sure there are many valid objections to it, an answer to some off the top of my head:
- What if some changes/migrations are destructive? I don’t want to let a tool do that automatically. – I don’t think you should necessarily let the tool run wild. There could be a command “migrate my schema” which asks you to confirm that the inferred migrations are correct and that you want to run them. The design may vary here.
- How do I know my migrations in production are going to be correct if they’re not explicitly defined? – There could be some tooling à la “convention over configuration” where you can either let the defaults run or specify them yourself. We could conceivably use this as a generator if one wishes in certain cases.
One thing in sure in my opinion, the process around migrations has a lot of space for improvement.