Hacker News new | ask | show | jobs
by MrStonedOne 1989 days ago
Modern ORMs don't let you hand craft sql, shunting it away in some scary extension that you then have to fight when management on using.

A ORM that worked on the principle of insert query text of any complexity receive object as the primary usecase, not the "nonstandard and non-idiomatic usecase" would be the only way to ease the concerns of dba's who code like me.

Its the same pitfall of api clients. Why would I take the time to learn an api like its a sdk, along with the pains of trying to shunt openapi's libraries in to my application without requiring the creation of a composer build step, further complicating deployment, when I can make 5 methods in the time before lunch to do the bits i need as rest queries and deployment of my php app remains as simple as `git pull production` on the nfs share all the workers read from?

The benefit of compile validated symbols is moot in the days of test driven dev, so the benefits gained from that can still be realized without creating build complexity or making competent engineers re-learn something they already know only re-abstracted in a way that almost always makes it harder for somebody who understands the low level to learn the new way compared to a new dev.

2 comments

You're not using a modern ORM then if you can't use manual SQL queries. And tests are not a replacement for compilation and type-safety.

Like I said, you're either using an existing ORM or just writing your own everytime, and the one you write probably won't be very good as seen by the numerous security and performance bugs that are constantly found. Also abstractions are useful. All of software development is built with abstractions and they don't suddenly become useless when it comes to databases.

I also don't see what this has to do with API clients or build steps, but there are good and bad examples of those too.

> I also don't see what this has to do with API clients

They are the same thing, a way of taking text based queries for formatted data as std:maps and shunting that away behind classes and types and interfaces.

> Like I said, you're either using an existing ORM or just writing your own everytime

vectors of maps works pretty well.

> Modern ORMs don't let you hand craft sql

What "modern ORM" are you using?

Sure I don't write PHP, but the ORMs I've used in Java/Kotlin, Ruby, JavaScript and lately Rust and Crystal have all been more than fine with me writing raw SQL.