One fun case I witnessed involved a junior developer adding the desired/resulting SQL as a comment to every complicated Rails AREL queries, so that people could know what the query was doing.
Then, after seeing that, one of the tech leads determined that EVERY query should have SQL on top of it, for consistency, even things like User.all had the `SELECT * FROM users` on top.
In hindsight it's funny but it was a terrible team and a terrible software.
Go shove your views up yours, you maniac!
/s, except for way many more ORM lovers than you think.
Finding data engineers that can actually do it will become difficult in just a bit, as there's a goldrush to take on that role, and lots of people want in with some rudimentary knowledge of SQL and Python.
Anyway, I'm always suspicious of people advocating for stored procedures, because those are version controlled if you're lucky, and I've yet to see them subject to automated testing.
And pgTap as an example of testing them https://pgtap.org/ .
What I'm suspicious is that, having seen untested stored procedures, you haven't bothered to try unit test them. I mean, you can do a lot with BEGIN; set db in good state; call procedure; ROLLBACK; but you have to try.
I haven't seen untested stored procedures in years, because I don't use them, no team I've been in uses them.
Complex prepared statements, that's common, but stored procedures, no.
I understand the sentiment but there is not anything inherently wrong with a stored procedure. If they came out today we'd probably call it edge computing.
If you mean stored procedures are harder to test than something like ORM in Django than that is just a huge misunderstanding of how you properly write stored procedures while also not understanding how hard it is to actually test a lot of ORM logic.
You test your app.
Also, not abusing database and writing code doesnt mean lets get deep into the ORMs madness.
You can do not write logic in db and still write raw sql