News for hackers. Stuff that matters.
Re:Why We Chose Rails to Build Gitlab by noir_lord on Tuesday January 22, 2019 @05:53PM (#18973475)
Or you inherit a DB that’s a complete disaster scheme wise and all the nice assumptions go out the window.

I’ve mostly found that migrations work best as a structure way to just run normal SQL and know a) what ran b) when.

For that they are handy.

I’ve even considered how to structure a stand alone migration running tool with a nice API since the good ones for each language tend to be fairly different.

It annoys me that the tooling around RDBMS in 2019 is still so shit.

Prime example, try to find a halfway reasonable way to debug a badly written MySQL sproc you inherited.

Re:Why We Chose Rails to Build Gitlab by adamson on Tuesday January 22, 2019 @05:59PM (#18973518)
I’ve used Flywheel (https://flywaydb.org/) for this exact problem on personal projects before and been fairly happy with it. It’s intended for use in JVM-based projects, but ships with a CLI that gets you a long way.
Re:Why We Chose Rails to Build Gitlab by FrancoisBosun on Tuesday January 22, 2019 @11:16PM (#18975633)
Sqitch by David Wheeler is a great way to manage database schemas. I haven’t uses it in production, because I mostly use Rails and haven’t felt enough pain to justify the switch.

https://sqitch.org