As is so often the case in Rails, it's set up to be nice and simple for a hello world example but little more. It doesn't actually make things as simple as they seem at first, and you're on your own to figure out which of its niceties are actually helpful and which are dangerous to use that you need to build your own workarounds for.
This is just wrong. Rails works very well for 90% of the situations. When it stops working that’s great news:
You’ve won!
You’re Twitter, Facebook or the next big thing. You’ll find talent and money to replace your rails app.
Can you name a framework where you roll back schema changes and don't lose data?
> being careful not to take down the whole thing
You still need this caution if you don't use rails
> a certain change required a full table lock or a certain index would take so long to create, etc.
I feel like you're just describing working with a relational database in a production setting. This isn't rails specific
> Rails, it's set up to be nice and simple for a hello world example
Sure. I'm also pretty sure it's used in production by some great companies whose applications/APIs are a pleasure to use - SendGrid, Github, Stripe, and last time I checked Hulu to name just a few.
Just because it's not the framework of choice for the majority of companies doesn't make it incapable of being used at scale.
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.
it's not the technical part (you can point slowness, quirks in how the language/framework is used) but the human and business part. It works. It makes adapting to change easy. Yes it's a monolith, yes it encourages fat models, etc. But it works so damn well.
`rake db:migrate` is not so great as a feature (other frameworks in other languages have it), the greatness comes from how well it's integrated with the Rails workflow.
Yep, Laravel (PHP) lifted it en masse (so much so that when I had to get up to speed with laravel years ago I used the rails docs to fill in the blanks) and Symfony with Doctrine is in some ways better.
.NET has db/schema migrations in Entity Framework.
Node/javascript has sequelize/umzug, node-db-migrate and others for db/schema migrations.
Migrations are pretty common now for ORMs, or any code first schemas, but are definitely a killer feature and needed with ORMs to see what is being changed/iterated on.
Postgres Tutorial: https://metacpan.org/pod/sqitchtutorial
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.
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
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.
Migrate has a different binary for each platform and from what I can see, the support for each database is compiled in, so just to update a driver you are going to be maintaining that binary all over the place.
$ time go test github.com/sapcc/limes/... | grep -v 'no test files'
ok github.com/sapcc/limes 0.004s
ok github.com/sapcc/limes/pkg/api 0.515s
ok github.com/sapcc/limes/pkg/collector 0.449s
ok github.com/sapcc/limes/pkg/core 0.006s
This type checks all ORM operations, and type checks against the actual schema at compile time. It's pretty cool and made by one of the long-time developers of ActiveRecord.