[andix]

Good ORMs let you use SQL statements wherever you need them. Go for it, if it’s easier, and let the ORM just map the results to objects.

And nothing prevents you from using plain SQL libraries next to an ORM. Good ORMs expose the database connection, so you can do whatever you want.

Every tool can be abused.

[doctor_eval]

The ORMs I’ve used also needed every entity from the database to be duplicated in the host language, which is a horrific amount of duplication in any non trivial project. Not just the entities but also the relationships. And then they need to be kept in sync.

And then they have these awful and subtle caching issues that mean if you fall back to SQL then you take a massive performance hit. Or if you run multiple servers against the same database you need another layer of complex caching infrastructure. Or if you update a table outside of the application you can get inconsistent results.

The whole thing is a nightmare of unnecessary complexity apparently intended to hide developers from the much lower complexity of databases.

ORMs are an inefficient, leaky and slow abstraction layer on top of a fast and complete abstraction layer.

I’ll never willingly use an ORM again.

Edited to add: the whole fragile contraption is done in an effort to move slices of the database into the memory context of a remote application. To what end? So we can update some counter and push the whole lot back out? It literally makes no sense.

[andix]

There are two ways to achieve a single source of truth:

1. Generate ORM entities from the database (usually there is a too for that) 2. Generate the database from ORM entities, and make changes via generated/manual migrations

You are supposed not to edit the generated side, just re-generate it on a change of the model.