[kaba0]

How do you map rows to objects? How do you insert into/update rows in your databases? These are the basic problems ORMs solve splendidly. They are for OLTP workloads, and have deliberate escape hatches to SQL (or some abstraction over it, like JPQL in java-land).

I just fail to see what else would you do, besides implementing a bug-ridden, half-ORM yourself.

[blksv]

Rows are tuples, not objects, and treated as such throughout the code. Only the needed data is selected in the form most appropriate to the task at hand, constructed in a hand-written sql query, maybe even taylored to the DB/task specifics. Inserts/updates are also specific to the task, appropriately grouped, and also performed using plain sql. Data pipelines are directly visible in the code, all DB accesses are explicit.

[couchand]

This. The right way to structure database access is a result type per tuple, not an object type per table.

[kaba0]

ORMs don’t mandate mapping the whole table either, you are free to create multiple entities per table/view.

[DangitBobby]

Maybe we need to use a different acronym than ORM, because to me the thing we can all agree we need is code that emits SQL. If you can't agree that projects need generated SQL because SQL is dog water for composition, then we can't really agree on anything.

[blksv]

Probably so: I can't agree with that particular inference.

1. Very often we need generated SQL because writing SQL for primitive CRUD operations is hell tedious and error-prone (as well as writing UI forms connected to these CRUD endpoints, so I prefer to generate them too).

2. Structured Query Language being very poorly structured is indeed a huge resource drain when developing and maintaining complex queries. PRQL and the like try to address this, but that's an entirely different level of abstraction.

3. Unfortunately, when efficiency matters we have to resort to writing hand-optimized SQL. And this usually happens exactly when we terribly need a well-composing query language.

[PeterisP]

I'd argue that "code that emits SQL" is never an inherent need but a possible development time-saver - we need code that emits SQL in those cases (and only those cases) where it saves a meaningful amount of development time compared to just writing the SQL.

[sgarland]

Every RDBMS has multiple connector libraries that solve this for you, without requiring the overhead of a full ORM.

[DangitBobby]

If the connector library solves this problem then the connector library is an ORM.

[sumtechguy]

That is exactly where ORMs help. The problem is all of the other stuff with it. When most people just need a simple mapper. Not something to build their SQL statements for them (which seems to be why most people pick it).

But that comes to the second problem. Most devs I meet seem to be deathly allergic to SQL. :)

One project I had a dev come to me asking me to look at a bug in the thing. Having never seen that particular ORM before I was able to diagnose what was wrong. Because MS ORMs have the same issues over and over (going back to the 90s). You better read those docs! Because whatever they did in this stack will be in their next one when they abandon it in place 3 years from now.

[to11mtm]

> These are the basic problems ORMs solve splendidly.

Depends on the ORM.

I have noticed that typically, 'unit of work' type ORMs (EFCore and Hibernate/NHibernate as examples) prevent being 'true to the ORM' but 'efficient'.

i.e. Hibernate and EFCore (pre 7 or 8.0ish) cannot do a 'single pass update'. You have to first pull the entities in, and it does a per-entity-id update statement.

> I just fail to see what else would you do, besides implementing a bug-ridden, half-ORM yourself.

Eh, you can do 'basic' active-record style builders on top of dapper as an afternoon kata, if you keep feature set simple, shouldn't have bugs.

That said, I prefer micro-ORMs that at most provide a DSL for the SQL layer. less surprises and more concise code.