[ElectricalUnion]

> I don't think providing 90% of the structure you need is a failed abstraction.

It is, when the "10%" is the actual hot queries that your system will use the most?

Code right now "is so cheap". You can provide your favourite LLM with your database schema, and some domain comments, and ask it a query to fetch/update data, and it will generate somewhat sane queries for you. You can then inspect those queries yourself, send them to another LLM or human to review and, when they look OK, ship it.

And when it comes time to debug it, you have, you know, an actual query, not some pseudo-query in a custom DSL. No need to implement runtime telemetry just to try to figure out if the ORM actually made the query you thought it was supposed to do.

[nodamage]

Even if you replace ORM generated queries with hand generated queries or LLM generated queries you're still missing a huge chunk of functionality provided by an ORM.

For my projects I would say that the majority of the value an ORM delivers occurs after the query has returned from the database.

But for some reason everyone focuses on query generation as if it were the only feature of an ORM.

[Charon77]

"after the query has returned from the database"

I have a lot of fighting against Spring / Hibernate for this. It doesn't let me do cartesian product because the query builder thinks it needs a cartesian product, I can't select only some of the columns without making a whole new data structure while fighting the ORM that thinks one table = one class, can't query from a joined table.

I don't have any issue with mapping using these query builders like jooq which lets you use generated class from the live db for simple use case and give you other mechanism for querying weird joins or aggregates.

What sort of perks of ORM after the query has returned do you find to be helpful?