What ORMs have taught me: just learn SQL (2014)

Post by fuzz4lyfe » Sat, Sep 21, 2019, 1:52 AM UTC

fastball wrote: post #284

sjwright wrote: post #233

Earlier quoted context omitted.

Even more advanced programmer: writing the ‘boilerplate’ queries out manually takes barely more time than composing them in an ORM, means less indirection, saves me a major dependency, and encourages me to think intelligently about each query no matter how boilerplate they might seem at the surface. Super-advanced programmer: allowing my database structure to be influenced by the needs of an off-the-shelf ORM will ma…

What ORM do people use that influences the structure of their database? The ORM I'm currently using the most can do whatever I need with my Postgres DB. Also, the ORM allows me to specify models that are not only used for structuring the database, but also for validation of incoming JSON requests and easily serialize queries back to JSON.

  import json
  data_from_json_request = json.loads(*request body*)

  import pymysql
  import json

  conn = pymysql.connect(*connection details*, 
                          cursorclass = pymysql.cursors.DictCursor)

  cur = conn.cursor()
  cur.execute(*query*)
  json_query_result = json.dumps(cur.fetchall())

Post by zem » Sat, Sep 21, 2019, 1:57 AM UTC

Post by weberc2 » Sat, Sep 21, 2019, 1:58 AM UTC

mst wrote: post #290

setr wrote: post #255

Earlier quoted context omitted.

Tbh you could easily claim that the explicit goal, mapping to objects, is incorrect. The real value is to reduce the damage of the SQL language itself — the unnecessarily ordered clauses, the arbitrary inconsistencies in syntax, the worthless parser errors, the lack of any static typechecking — which cause so much code bloat and debug headaches. There are two reasons to use the ORM: to not learn SQL, and to generate…

An ORMish thing that considers its primary purpose to enable metaprogramming SQL is actually useful. In http://p3rl.org/DBIx::Class perl has had such a thing for over a decade now. It makes me cry that nobody's ever adequately cloned it into other languages. Eventually I'll probably do so myself.

Post by learc83 » Sat, Sep 21, 2019, 2:02 AM UTC

wvenable wrote: post #30

daenz wrote: post #14

ORMs lure you in with a false sense of neat abstraction. They have nice intuitive examples on their home pages. But then you use them in the real world, doing gnarly queries, and you realize that doing anything powerful and fast in the ORM requires its own completely separate abstractions, which are often difficult for the uninitiated to follow. It's also often a big pain to debug the raw SQL that gets compiled after…

You don't use ORMs for gnarly queries -- that's not what they are for! They are for making manipulating the entities easier -- reading the data out of the database in a way that makes easy to modify. You can (and should) use them for simple queries. You have a list of entities you want to query and filter, that's going to be fine. Joins are fine. But if you're doing some complex analysis, an ORM is the wrong tool. Th…

Post by conroy » Sat, Sep 21, 2019, 2:02 AM UTC

brianm wrote: post #207

conroy wrote: post #28

If you use Go and PostgreSQL, I’ve been working on a tool to help you “just use SQL” called sqlc[0]. It generates methods and structs for your queries, automatically. It’s made a dramatic difference in my day-to-day workflow. [0] https://github.com/kyleconroy/sqlc

I really like this! I particularly like that it is oriented around a useful workflow, rather than for just "small code at rest". It looks like it parses the schema to find type information (2 minute skim, so please forgive me if I got it wrong!) Hoe does it handle schema changes?