Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
I've never worked on a codebase where using ORMs wasn't better than rolling your own queries. What are people writing that they actually need the marginal performance gains? And even if that's worth it, why not just use raw queries in your critical paths?
Every time I have to write or modify raw SQL it feels like I'm throwing away all my static checking features and increasing the chance of bugs, because I have no idea of the query matches my schema or if it'll blow up at runtime.
I worked in a codebase at a FAANG company that didn’t have an ORM and it was the most miserable thing to write and code review. Constantly there would be bugs in queries and types. I missed having an ORM so much.
Your last paragraph can be fixed even without an ORM though. Rust has libraries like diesel and sqlx that verify the sql in various ways.
I consider the ORM hate uninformed and misguided at best. Just like any other technology not all of them are created equally there are better ones and worse ones. I have used Entity Framework Core for years and have almost no complaints but If I only knew ORMs like NHibernate then I might have a different opinion.
Two choices always seem to end up as the fate of any large scale, long-term developed database application. Either you use an ORM, or you build your own piece by piece. I know which one makes more sense to me.
Same goes for any application that are proud to use "no framework". It just means that you partially implemented your own poorly documented half-assed framework.
It's a little more nuanced than that.
I will gladly write my own small, half-assed framework that I 100% know, can reason about, can debug, and can extend to fit my requirements. I will gladly pass on a fat-assed, bloated framework with a million dependencies, where I only need a few features, and where if I need something that isn't offered by the framework I have to submit a PR or add some janky-ass workaround.
That is fine for your personal projects. It stops being fine as soon as you need to hire extra people and grow the team.
Does it, if you can work on the normal application code, there's no reason you can't work on the lower levels of applications. It's all just code. Ramp up might take a bit more time, but I wouldn't expect horrendously so. As long as your patterns make sense and what is there is written well enough and is not a spaghetti monster in the making, any one should be able to pick it up.
Why though?
I love asking new hires about ORMs. If they don't have anything bad to say about them I know they've never used them.
I like ORM's because they prevent sql injection. Mostly. Sql injection is a really bad vuln that's nowhere near as ubiqitous as it used to be for every php app, and that's partly due to ORM's.
You don't need ORMs to prevent SQL injection. Prepared statements have existed for decades.
That's what I thought too: https://programming.dev/comment/22854391
But it seems to be possible to still do them wrong.
If you don't use the parameter functionality of prepared statements, yeah. That also means you don't use a prepared statement, you construct varying sql strings and prepare varying "prepared" statements.
It's a bit sad that sql injection is still a thing. It's been a known problem for decades, and developers keep itching to reinvent the vulnerability over and over...
ORMs are a pain and so is hand rolling SQL queries and doing the mapping manually.
I definitely think there's scope for NoSQL databases where the database "shape" matches the normal struct style of programming languages. Kind of like how JSON does and XML doesn't.
But it seems like all we got was MongoDB and Firebase which are both shit.
Are there any good NoSQL databases? MongoDB and Firebase don't even have schemas.
Postgres jsonb?
Mongoose solves the schema part, or typegoose is you want it to generate types on the go as well.
My problem with mongo is that I always end up realising the advantages of SQL down the line, but I guess many of those projects wouldn't have gotten that far without mongo being so damn nice in the beginning.
The real problem is that most data is inherently relational, and trying to force it into a document database is just as problematic as ORMs are.
I don't see why you couldn't have relations in a object model database. Just allow fields that are references to other objects or their keys.
Having seen what the ORM hate leads to. Just use the ORM folks. Far better in the long to do so! Nothing has come close to ActiveRecord imo in Typescript or Python sadly. Unless anyone has a library or two I should check out?
Haven't tried it, but functional programming methods (as in Clojure) combined with Datomic / Datalog sound interesting. It is said to be quite good.
I’m starting to think more that I shouldn’t call my library, Numph.js, an ORM. It technically is one, but it’s very different than other ORMs. A lot of the stuff he’s talking about here doesn’t apply to Nymph (for better or for worse). I just don’t know what to call it though.