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

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

#291

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

One of the biggest problems with ORMs is that they encourage unstructured SQL access. What queries does the application run? With an ORM, it's impossible to know, because relation-fronting objects are available everywhere in the code, and that means any module could be composing or adjusting queries.

A logical thing to do is restrict these kinds of actions to a database module, which exposes a function for each query we want to run against the database. This is a lot like the stored procedure model, with the procedures in the app (and adjustable from the app) instead of in the database. With a structure like this, it isn't so bad to write all queries as SQL files with some template parameters. Maybe there is repeated logic but there is usually a SQL templater for your language that lets you template in table names. There is abstraction, there is clarity about what code is being run, there is control over performance, there is syntax highlighting.

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

#292

Post by dfilppi » Sat, Sep 21, 2019, 1:22 AM UTC

Amen brother

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

#293

Post by fastball » Sat, Sep 21, 2019, 1:22 AM UTC

daenz wrote: post #152

wvenable wrote: post #145

Earlier quoted context omitted.

You would need to show me your DDL statements because that's the equivalent. I can generate the model from the database or the database from the model. It's not much more effort to type "create table employees" with all the fixings as it is to type "class employees" with all the fixings.

>I can generate the model from the database or the database from the model. Depends on the ORM. Just like "raw sql mode", not every ORM supports that. It's not an inherent feature of being an object-relational mapper, it's part of the bells and whistles of some ORM packages. And I'm going to guess you're coming from the Python/scripting universe, because generating models in other languages is definitely more complic…

I think I can give a better example that isn't purely about performing updates, but is still about "simple things" and not particularly complex flows.

In my API, I have models from my ORM. These can then be used for database migrations, which allows changes in my database structure to be checked in to version control.

From there, these models are obviously used for queries within my app. Generally, you are correct that generating a simple query with the ORM is not meaningfully easier than writing the SQL myself, with the one exception being that the ORM sanitizes inputs to my queries without me having to think about it at all, which is nice.

From there though, I can use the models from my ORM to automatically validate incoming requests to the API endpoints, as well as automatically serialize the results of my queries when I want to send a response back to the client. If you're not building a REST API, obviously this might not be particularly useful, but for someone that is, it has saved me a lot of work.

Finally, generally I find code in my code is a bit easier to debug than strings.

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

#294

Post by mst » Sat, Sep 21, 2019, 1:23 AM UTC

sjwright wrote: post #233

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.

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.

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

#295

Post by strokirk » Sat, Sep 21, 2019, 1:23 AM UTC

pknopf wrote: post #283

ratww wrote: post #271

Earlier quoted context omitted.

But Micro-ORMs are ORMs. And you're right, they do remove a lot of boilerplate.

> But Micro-ORMs are ORMs. Not in the traditional sense. > And yes, they do remove a lot of boilerplate. Here is all the "boiler plate" you'd need to use something like OrmLite with C#. https://pastebin.com/XUhQVPUk Type safety. No boiler plate. No abstractions. Errors are a result of the underlying data storage. This is where it's at. The sweet spot.

You're agreeing with each other - the ORM reduces the need for annoying and typo-inducing boilerplate.

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

#296

Post by mst » Sat, Sep 21, 2019, 1:24 AM UTC

icheishvili wrote: post #256

pjungwir wrote: post #235

Earlier quoted context omitted.

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…

AR is the gold standard. AR + extended gem + Arel covers almost 100% of the problem space. For everything else, use views or set returning functions and wrap them up in AR.

AR took at least ten years to catch up with the perl state of the art but does seem to be doing pretty well these days.

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

#297

Post by strokirk » Sat, Sep 21, 2019, 1:24 AM UTC

djrobstep wrote: post #285

wvenable wrote: post #61

Earlier quoted context omitted.

ORMs let you drop into SQL whenever you need, usually in a way that is fully compatible with the model, so that's entirely false.

That's absolutely not true. With any of the ORMs I've used, as soon as you do something even slightly unorthodox like using a view, you're on your own.

Which ones have you used?

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

#298

Post by lugg » Sat, Sep 21, 2019, 1:25 AM UTC

graphememes wrote: post #265

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…

10x programmer: I used a tool and it did all the work and now I can move on to the next thing

Clojure programmer: I'm never going to run out of work replacing these 10x masterpieces.

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

#299

Post by rmilejczz » Sat, Sep 21, 2019, 1:27 AM UTC

dymk wrote: post #246

vbezhenar wrote: post #245

Earlier quoted context omitted.

Sometimes you just should live with duplicated code. It's OK.

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

An in house solution is almost always better than an external dependency

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

#300

Post by philwelch » Sat, Sep 21, 2019, 1:30 AM UTC

matthewmacleod wrote: post #55

philwelch wrote: post #4

I’ve come to the same conclusion even working with ActiveRecord. SQL is very literally a domain-specific language for working with relational data; why would we go so far out of our way to eschew writing code in it?

Because the process of building that SQL, executing it, and bringing the data it returns into the object oriented universe is a tedious and fiddly pain in the arse.

1. “Building SQL”? It’s not clear to me what that means in a world where you are writing raw SQL rather than using ORM’s and query builders.

2. “Executing it”—this is called a SQL client library. If you install your SQL statements as stored procedures you can execute those procedures by name, for example. Not that hard.

3. “Bringing the data it returns into the object oriented universe”: I am typically satisfied with an array of hash tables. Funny story: what do you get when you use ActiveRecord’s find_by_sql with a query that returns columns not in the original table? You get a collection of objects each with the extra column monkey-patched to the individual object. In other words, a slower and stupider hash table that happens to have dot syntax rather than bracket syntax and a bunch of do-they-even-still-work-in-this-context instance methods attached.