1) I'm querying JSONb for that from postgresql and then the conversion to Ruby types is trivial.
2) Parameterized queries and you don't have SQL injection
3) The migration tool is a script of a few lines (bash in my case). It has a "migrations" table, it reads a list of migration files in a migration dir, check which ones don't exist in the migrations table and runs them in order. A migration file is just a .sql file
My whole setup is a few lines of code. A very small library covering the first two, a small script for the third one.
I get it, but I want to use SQL. It's a lingua franca and has a lot of power for writing migrations that I'd rather use than inventing my own.
That said, it's awesome to hear from someone using jsonb with migrations. Most places I've seen using jsonb push responsibility for handling different schemas onto the application, which <shudder>.
I think I expressed myself in a confusing manner.
I write _SQL_ for migrations and nothing else. What I meant was that in order to _run_ the migrations it's enough to have a simple bash script of a few lines (which basically calls psql, ls and feeds the sql migration files in order).
I don't use jsonb with migrations. My migration files look like
migrations/1645698230_create_orders.sql
create table orders (.... );
migrations/164595623_setup_some_trigger.sql
create trigger...
--------
In response to "Elimination of boilerplate to load data from a table into a type"
Unrelatedly to migrations, when working with postgres, I use postgres'json capabilites to get nice nested structures that I can convert to any other language easily (or even send it to the browser if serving a webpage). Instead of using tabular responses, I get json structures _directly_ from postgresql.
Very often I just write SQL queries that return a single row with a single json/jsonb field that has the whole JSON response to be served to a web endpoint. Basically I write most if not all my webservice in SQL. And I just have a very thin layer of a server language to work as a proxy between a frontend application and my database application (written in SQL).
- Elimination of boilerplate to load data from a table into a type - A reasonable query mechanism that avoids SQL injection - A migration tool
Every ORM I've used solves the first problem (for which I'm grateful). Some do the others. Most do way too much more.
I still use an ORM in every non-trivial project because I don't want to do these things by hand. But it could be much better.