3 ms·
Hmm -- most migrations don't need to be reversed, not sure what the 'down' section does in those cases. The more important problem in DB migrations is transfor
by awinter-py 10y ago
Hmm -- most migrations don't need to be reversed, not sure what the 'down' section does in those cases.
The more important problem in DB migrations is transforming the content (usually involves application code) and resolving relational changes (i.e. 'in v2 all users are a member of a group').
Some large companies handle migrations by versioning the data and branching the code to handle every version. Another alternative is to 'migrate on read'.
Both of those options sound worse on paper than an all-at-once migration but one-shot upgrades can be expensive and dangerous on large databases. Dealing with data-versions explicitly also makes sense for data that's stored client-side and periodically synced.
- Kiro 10y ago> most migrations don't need to be reversed What do you mean? That's like saying "most commits don't need to be reverted".
- awinter-py 10y agoBut git rollback is something you get for free. These 'down' commands have to be written and tested.
- GrinningFool 10y ago> Hmm -- most migrations don't need to be reversed, This is true - but when something does break unexpectedly in a production migration, the last thing you want to do is figure out how to do your revert/'down' on the fly.
- awinter-py 10y agoOkay, but are you testing every 'down' command on your prod DB? Large untested operations in prod may not be the best answer in an emergency.
- tomcam 10y agoGreat getting a perspective from the trenches, thank you. Never heard of forking code for each migration.
- elwinar 10y ago> most migrations don't need to be reversed I agree, in which case, you don't have to write a down section. Anyway, rambler isn't targeted at "large companies with huge databases", which of course have more complex database migrations methods.