6 ms·

This thread only underscores the total mindshare dominance of ORMs. The implicit alternative to ORMs in almost every comment is raw sql in string literals in ap

This thread only underscores the total mindshare dominance of ORMs. The implicit alternative to ORMs in almost every comment is raw sql in string literals in app code. For 6 years now, we've had tools that let you use sql as a language, then generate the wrapper exposing your query to your app as a method. (queryfirst, pgtyped, pugsql, sqlc) This is (or could be) a paradigm shift. It's clearly, demonstrably a superior way of working, but it exists on the fringes because ORMs (and this unchanging discussion) have sucked all the oxygen.

kubanczyk 3y ago
Yes, this. Also sqlc in Go. SQL is a language, an extremely high-level one at that. Trying to stitch it together using a lower-level language is a prime example of "if you have a hammer, every problem looks like a nail". An illustration. Let's say I'm coding in assembly (low-level) and I interact with a large system. The system's docs say that the input can only be formulated in Java Script (higher-level than assembly). So there's the choice: I can either import an arcane library that allows me to stitch something in pure assembly, without ever committing xxx.js file to repo. Or, I can express myself in .js files, using the power of a high-level language.
bruce343434 3y ago
Which tools then?
- laeri 3y ago
  They specifically mentioned them (queryfirst, pgtyped, pugsql, sqlc)
  - bbsimonbb 3y ago
    also zapatos, scala-slick (see type-checked sql statements) and yesql
    - bbsimonbb 3y ago
      datagrip in pycharm seems to be on a similar trip. The SQL stays in string literals, but datagrip looks inside the string literal to validate and propose auto-completion.
  - bruce343434 3y ago
    Ah I see, not when I replied. That, or I read over them.
Karupan 3y ago
100% this! After using sqlc for a project, I don't think I can ever go back. Having a single source of truth for the SQL queries being utilised also makes it easy to optimize queries (e.g. create new indexes) since the queries themselves are the thing you end up writing and maintaining.
sanderjd 3y ago
I always disliked ActiveRecord, and always really liked arel, which is what it uses to construct its queries. Abstracting over raw sql strings is very useful, but pretending that relations are objects is convoluted.
eschaton 3y ago
NeXT’s Enterprise Objects Framework supported this 25+ years ago. (And TopLink probably did too.) This is how it handled mapping between stored procedures and local entities.
- bbsimonbb 3y ago
  The wikipedia page says exactly the opposite. "EOF abstracts the process of interacting with a relational database by mapping database rows to Java or Objective-C objects. This largely relieves developers from writing low-level SQL code." https://en.wikipedia.org/wiki/Enterprise_Objects_Framework https://en.wikipedia.org/wiki/Enterprise_Objects_Framework
  - eschaton 3y ago
    What I said is not mutually exclusive with that. I said that’s how EOF maps stored procedures to local entities. EOF also maps tables to entities and supports queries via its own qualifier (predicate) syntax. It’s not exclusive to one or the other.

kubanczyk 3y ago

Yes, this. Also sqlc in Go. SQL is a language, an extremely high-level one at that. Trying to stitch it together using a lower-level language is a prime example of "if you have a hammer, every problem looks like a nail". An illustration. Let's say I'm coding in assembly (low-level) and I interact with a large system. The system's docs say that the input can only be formulated in Java Script (higher-level than assembly). So there's the choice: I can either import an arcane library that allows me to stitch something in pure assembly, without ever committing xxx.js file to repo. Or, I can express myself in .js files, using the power of a high-level language.

bruce343434 3y ago

Which tools then?

laeri 3y ago
They specifically mentioned them (queryfirst, pgtyped, pugsql, sqlc)
- bbsimonbb 3y ago
  also zapatos, scala-slick (see type-checked sql statements) and yesql
  - bbsimonbb 3y ago
    datagrip in pycharm seems to be on a similar trip. The SQL stays in string literals, but datagrip looks inside the string literal to validate and propose auto-completion.
- bruce343434 3y ago
  Ah I see, not when I replied. That, or I read over them.

Karupan 3y ago

100% this! After using sqlc for a project, I don't think I can ever go back. Having a single source of truth for the SQL queries being utilised also makes it easy to optimize queries (e.g. create new indexes) since the queries themselves are the thing you end up writing and maintaining.

sanderjd 3y ago

I always disliked ActiveRecord, and always really liked arel, which is what it uses to construct its queries. Abstracting over raw sql strings is very useful, but pretending that relations are objects is convoluted.

eschaton 3y ago

NeXT’s Enterprise Objects Framework supported this 25+ years ago. (And TopLink probably did too.) This is how it handled mapping between stored procedures and local entities.

bbsimonbb 3y ago
The wikipedia page says exactly the opposite. "EOF abstracts the process of interacting with a relational database by mapping database rows to Java or Objective-C objects. This largely relieves developers from writing low-level SQL code." https://en.wikipedia.org/wiki/Enterprise_Objects_Framework https://en.wikipedia.org/wiki/Enterprise_Objects_Framework
- eschaton 3y ago
  What I said is not mutually exclusive with that. I said that’s how EOF maps stored procedures to local entities. EOF also maps tables to entities and supports queries via its own qualifier (predicate) syntax. It’s not exclusive to one or the other.