4 ms·
I thought the established wisdom is to make schema migration compatible with both the old app and the new app, whenever it is possible? E.g. you can safely add
by throwdbaaway 5y ago
I thought the established wisdom is to make schema migration compatible with both the old app and the new app, whenever it is possible? E.g. you can safely add a nullable column, and it shouldn't trip up the old app nor the new app, unless you are using some crappy ORM that does "SELECT *", or you are on an older MySQL version that may take hours/days/weeks to rewrite the whole table just to add a nullable column.
https://github.com/fabianlindfors/reshape https://github.com/fabianlindfors/reshape, on HN front page a couple weeks ago, has some nice tricks to help with the incompatible cases.
- jrockway 5y agoI think that's the established common wisdom, but it's not well-enforced by anything, and it's not innate. Everyone learns this the hard way once.
- throwdbaaway 5y agoRight, I did have to learn this the hard way back in 2014.
- jokethrowaway 5y agoI would say a fair share of companies bent on following good practices do that. It's not all of them or not even the majority but I haven't seen cowboys migrations in 10+ years
- kodah 5y agoYou can get by on that "wisdom" for a while, but eventually your DB will garner a significant size and performance impact as a result. That said, even on very active products that takes a while, so there's probably something to blending the idea of one large migration every so often and only making schema compatible changes along the way.