[stephen]

You're right, that has been another "pro ORM" pitch that has gone awry and, taken to the extreme, is wrong imo.

My nuanced articulation is "you don't have to write the _boilerplate_ SQL for the 90% of just-do-some-CRUD endpoints in your enterprise SaaS application, but you 100% need to 'know SQL' for the last 5-10% of ~reporting/analytics queries that the ORM is going to mess up".

[bluefirebrand]

Personally I find the 90% boilerplate SQL is easy enough to write that injecting an ORM into the process doesn't make much sense

But that's just me

[marcosdumay]

AKA making the easy parts easier while making the difficult parts harder.

[airstrike]

The difficult parts are just literally a raw SQL string so how is that any harder?

[marcosdumay]

That you somehow have to adapt the results into the same format the ORM uses. And has to adapt the parameters into taking data from the ORM. Or has to split your entire functionality from the ORM so you can actually access the database directly without one part of your code interfering with the others.

[jcgl]

No? ORMs don’t preclude writing raw SQL, so it’s just making the easy parts easier while leaving the difficult parts the same.

[bluefirebrand]

The ORMs I've tried tend to produce some pretty specific table structures that are a pain in the ass to work with outside of the ORM, imo

One of the sticking points I've found in the past is if I create a new table outside of the ORM, it doesn't know how to use it. Then if I try to add it to the ORM's model it doesn't use the existing table, it creates a conflict. Annoying stuff like that