3 ms·

> Folks who dislike ORMs seem to have this false dichotomy that "the ORM _must_ be used for all queries", which is a self-imposed/unpractical restriction. I've

> Folks who dislike ORMs seem to have this false dichotomy that "the ORM _must_ be used for all queries", which is a self-imposed/unpractical restriction. I've always heard a major selling point of ORMs is "You don't have to write the actual SQL anymore" Because of that, I tend to not trust people who use ORMs to even know how to write queries by hand in the first place

stephen 4mo ago
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".
- marcosdumay 4mo ago
  AKA making the easy parts easier while making the difficult parts harder.
  - airstrike 4mo ago
    The difficult parts are just literally a raw SQL string so how is that any harder?
    - marcosdumay 4mo ago
      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 4mo ago
    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 4mo ago
      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
- bluefirebrand 4mo ago
  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

stephen 4mo ago

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

marcosdumay 4mo ago
AKA making the easy parts easier while making the difficult parts harder.
- airstrike 4mo ago
  The difficult parts are just literally a raw SQL string so how is that any harder?
  - marcosdumay 4mo ago
    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 4mo ago
  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 4mo ago
    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
bluefirebrand 4mo ago
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