News for hackers. Stuff that matters.
Re:Why We Chose Rails to Build Gitlab by mythrwy on Tuesday January 22, 2019 @04:50PM (#18972919)
I sometimes suspect a folder full of sql scripts would be better than black box migrations (which are a folder full of sql scripts or similar anyway).

Migrations are great, until they aren't.

Sometimes if you actually manually do the thing you know how it works better and can adjust. I suppose the drawback to that is everyone else doesn't.

Re:Why We Chose Rails to Build Gitlab by evanelias on Tuesday January 22, 2019 @11:00PM (#18975573)
Another option is a schema management tool that doesn't rely on migrations at all. I'm the author of one, Skeema [1], for MySQL/MariaDB. Others include migra [2] for Postgres, and sqldef [3] for MySQL or Postgres.

These all use a declarative approach [4], where the user just specifies the desired new state, by adding or changing the set of CREATE statements. The tool knows how to run the correct DDL to reach that new state.

[1] https://github.com/skeema/skeema

[2] https://github.com/djrobstep/migra

[3] https://github.com/k0kubun/sqldef

[4] https://www.skeema.io/blog/2019/01/18/declarative/

Re:Why We Chose Rails to Build Gitlab by mythrwy on Wednesday January 23, 2019 @02:11PM (#18981551)
How Interesting. Thanks!
Re:Why We Chose Rails to Build Gitlab by gwillz on Tuesday January 22, 2019 @05:20PM (#18973184)
Yeah I've thought the exact same thing before and I've actually tried both.

The clear difference is that migrations are easily reversible. Good migration libraries can also reverse data migrations.

A folder of SQL scripts was very refreshing, but no way could I use that system in a production environment. There's just too many edge cases to keep in your head.

Re:Why We Chose Rails to Build Gitlab by mey on Tuesday January 22, 2019 @05:29PM (#18973253)
Manually migrating has the issue of testability and hit by the bus. I don't believe every migration needs a roll back, sometimes the better strategy is restore from a snapshot/backup.