[manigandham]

> "Attempts to avoid this with ORMs usually replace an annoying amount of typing with an annoying amount of magic and loss of efficiency."

People seem to keep using poorly-designed ORMs or are stuck with some strange anti-ORM ideology.

Modern ORMs are fast, efficient, and very productive. If you're working with relational databases then you're using an ORM. It's a question of whether you use something prebuilt or write it yourself (since those objects have to be mapped to the database somehow). 99% of the time, ORMs generate perfectly fine SQL (if not exactly what you'd type anyway) while handling connections, security, mapping, batching, transactions, and other issues inherent in database calls.

The 1% of the time you need something more complex, you can always switch to manual SQL (and ORMs will even let you run that SQL while handling the rest as usual). The overall advantages massively outweigh any negatives, if they even apply to your project.

[nine_k]

IMHO, ORMs are a wrong abstraction. Full-fledged objects are a wrong abstraction of the data in more cases than not.

The right tool is a wrapper / DSL over SQL, which allows to interact with the database in a predictable and efficient way, while not writing placeholder-ridden SQL by hand. Composable, typesafe, readable.

ORMs do fine in small applications without performance requirements. The further you go from that, the less adequate an ORM becomes, and the more you have to sidestep and even fight it, in my experience.

[manigandham]

Do you have an example of the right tool? SQL is already a DSL and I can't see how creating another language isn't just adding more overhead without actually getting you to usable objects.

The only reason objects are the "wrong" abstraction is because they don't match relational models exactly. That impedance mismatch is the entire reason for the object-to-relational mapping, otherwise you can use things like document-stores and just serialize your objects directly.

[nine_k]

SQLAlchemy gives a nice composable DSL in Python; it has an ORM layer on top of it, too, but it's optional.

JOOQ allows for composable typesafe SQL in Java.

[jsumrall]

+1 for jOOQ!

[MrStonedOne]

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.

[manigandham]

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.

[MrStonedOne]

> 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.

[filleduchaos]

> 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.

[Cthulhu_]

> Modern ORMs are fast, efficient, and very productive.

The author seems to be using Go, which honestly could use work in that area. gorm is the biggest / most popular ORM out there, but it looks like a one-person project, the author seems well worn-out already, and it kinda falls apart when you work with a data model more than one level deep.

Plus broadly speaking, there seems to be a bit of an aversion to using libraries in the Go community.

[MrFlynn]

GORM is nice for beginners because it's pretty easy to get started with, but in my experience starts to fall apart when you need to do anything more complex or start to scale up. I've had good experiences with SQLBoiler [0] on the other hand. I haven't used it in for anything in production, but it's been a breeze to use in a couple of personal projects, and it handles complex SQL queries much better compared to GORM.

0: https://github.com/volatiletech/sqlboiler

[gher-shyu3i]

> Modern ORMs are fast, efficient, and very productive

Which ones do you have experience with?