What ORMs have taught me: just learn SQL (2014) • Hacker News Board

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

#361

Post by nycdotnet » Sat, Sep 21, 2019, 2:45 AM UTC

pjungwir wrote: post #235

stickfigure wrote: post #208

Beginning programmer: ORMs let me write code without learning SQL! Intermediate programmer: ORMs just get in the way! SQL isn't that hard after all. Advanced programmer: I write a lot of SQL, but I use ORMs to cut out most of the boilerplate.

That's pretty much exactly how I feel. I gave a talk a few years ago about doing advanced SQL things in ActiveRecord [0]. The talk suffered I think from lacking a unifying idea and because I tried to offer something to the whole spectrum of experience (from "this is a join" to "this is how you can express a CTE/lateral join/window function in AR"), but the real unifying motivation/message was that with AR you can hav…

using Dapper at least?

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

#362

Post by brianpan » Sat, Sep 21, 2019, 2:46 AM UTC

zmmmmm wrote: post #352

Writing SQL is a lot of work, not type safe (in the programming language static typing sense), often not re-usable, and hard to test. There are libraries that solve these parts for you (or at least help with them). For me the optimum is libraries that do only these parts but actively try to NOT introduce any new layer of abstraction over the database model itself. The problem is that in this whole ORM discussion, the…

I’ve had success in Java with Freemarker. It’s a templating engine so you’re just producing strings. But you can add typing; use variables, loops, and conditionals; and include other templates for sub query reuse.

IntelliJ has a plug-in.

It’s a nice compromise between crafting strings vs SQL DSL.

As for the objects, you can get very far with everything being a Map until you really need to add a class or two. :)

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

#363

Post by ydnaclementine » Sat, Sep 21, 2019, 2:50 AM UTC

Personally, I feel like a very similar article could have been written called 'What CoffeeScript has taught me: just learn Javascript'.

I have nothing against coffee or typescript (and other alternatives) and think they're very useful, but at the end of the day it's really just javascript. But I guess you could make that argument about anything until you get down to machine code.

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

#364

Post by couchand » Sat, Sep 21, 2019, 2:52 AM UTC

sgk284 wrote: post #187

kbenson wrote: post #143

Advocating for the use of SQL over an ORM in every case is like advocating for the use of Assembly over C in every case. In both cases, one is a higher level abstraction over the lower level capabilities, which can provide a quite large gain in usability and ability to easily understand what is going on at the level you are working at, for the loss of hand optimizing at a low level to get just what you want in every…

What a weird statement. In many ways, SQL is a higher-level abstraction than an ORM. A better analogy might be functional versus imperative styles, but even that breaks down pretty quickly. ORMs generally serve some subset of three purposes: 1) constrain the dynamic nature and expressiveness of SQL in such a way that it can work well in less expressive languages 2) serve as a bridge between a typed language and an un…

> 3) a way to avoid your team needing to learn and work in two languages for backend dev (similar to arguments of using Node so that your frontend and backend can be the same language)

It's not about learning or working in multiple languages, it's about duplicating the specification of important details.

The holy grail would allow me to write critical business rules in one place, then make use of them everywhere. I want to only have to specify once that `email` is required on `contact`, and have that manifest as `NOT NULL` on the database, an API validation, and a little star next to the field on the UI. Unfortunately, there doesn't yet seem to be a solution to that problem.

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

#365

Post by fastball » Sat, Sep 21, 2019, 2:56 AM UTC

fuzz4lyfe wrote: post #321

fastball wrote: post #284

Earlier quoted context omitted.

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.

> incoming JSON requests import json data_from_json_request = json.loads(*request body*) > easily serialize queries back to JSON 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()) I don't feel that a ORM is better than this personally. I know exactly what this is doing…

Sorry, maybe I wasn't being clear. I don't just validate that the request is JSON, I validate that the fields in the JSON are valid fields to send over the wire. I do this by automatically hooking my ORM models into my request validation. If a request doesn't specify a column that is NOT-NULL, for example, it will automatically send an error response telling the client that it needs to specify that column in the request JSON.

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

#366

Post by mbell » Sat, Sep 21, 2019, 2:58 AM UTC

lugg wrote: post #288

dymk wrote: post #246

Earlier quoted context omitted.

But you shouldn’t live with a hand-rolled pseudo ORM that stumbled into existence when there’s developed alternatives

Why not? I've used hand rolled pseudo ORMs before. I prefer just plain SQL but for the application I had there was a common access pattern that was worth abstracting out in a DRY sense. That doesn't mean I want or need a complete ORM. Just a consistent access at certain table types.

> I've used hand rolled pseudo ORMs before.

Is your pseudo ORM as well documented as a commonly used ORM? Can I google (or search your wiki) for common issues?

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

#367

Post by sjwright » Sat, Sep 21, 2019, 3:02 AM UTC

mst wrote: post #294

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…

If your ORM influences your database structure, either your ORM is shit or you don't know how to use it yet. ... or both. Both is always a possibility. Welcome to programming.

If the object reasoning inherent in ORM design isn’t influencing your structure, either your structures are trivial or you don’t know how to use the full capabilities of your engine yet.

... or both. Both is always a possibility. Welcome to databases.

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

#368

Post by LeonB » Sat, Sep 21, 2019, 3:03 AM UTC

scarface74 wrote: post #340

lugg wrote: post #288

Earlier quoted context omitted.

Why not? I've used hand rolled pseudo ORMs before. I prefer just plain SQL but for the application I had there was a common access pattern that was worth abstracting out in a DRY sense. That doesn't mean I want or need a complete ORM. Just a consistent access at certain table types.

I’ve never seen a homegrown ORM that was better than a third party one. Whenever there is an issue - and there are always issues - you have to dig into the code, because they are never documented well. There is usually a feature that no one thought about and then you have to make modifications to the custom ORM and you get an even bigger mess.

sort of agree but also: the good third party ORMs started life as homegrown ORMs.

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

#369

Post by fuzz4lyfe » Sat, Sep 21, 2019, 3:07 AM UTC

fastball wrote: post #365

fuzz4lyfe wrote: post #321

Earlier quoted context omitted.

> incoming JSON requests import json data_from_json_request = json.loads(*request body*) > easily serialize queries back to JSON 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()) I don't feel that a ORM is better than this personally. I know exactly what this is doing…

Sorry, maybe I wasn't being clear. I don't just validate that the request is JSON, I validate that the fields in the JSON are valid fields to send over the wire. I do this by automatically hooking my ORM models into my request validation. If a request doesn't specify a column that is NOT-NULL, for example, it will automatically send an error response telling the client that it needs to specify that column in the requ…

Python doesn't have type safety to begin so those sort of checks have less utility to me and since json.loads returns a dictionary and python objects are effectively dictionaries you are pretty much done.

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

#370

Post by i_am_nomad » Sat, Sep 21, 2019, 3:08 AM UTC

gernak wrote: post #349

wvenable wrote: post #30

Earlier quoted context omitted.

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…

>You can (and should) use them for simple queries. This is not a very compelling argument to use ORMs. It is saying "it makes easy things easier". This doesn't really buy you much value. The simple things are already simple. Bringing in a very large, complicated external dependency to make simple things simpler, is not a good idea. >If you're loading data into objects then you're just creating your own personal ORM a…

This kind of doctrinaire thinking, this sort of broad and bold declaration, is the stuff of high-traffic blog posts but not good advice for real world developers.

Django, just as an example, does a magnificent job with its built-in ORM. Millions of developers use it, and they are not all fools. A fool is someone who would set out to build a simple-to-intermediate CRUD web app by writing SQL.