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

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

#311

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

Composible ORMs (for me, AR+Arel, this was about 4 yrs back) let me write some of the most magical, legible query code I have ever seen. I could create and reason about subqueries with highly dynamic filter options and pass them around and wrap them with outer queries, all in. perfectly readable code. Glorious.

Of course, for complex analysis like in specific periodic data reports, where the filter parameters are mostly known and don’t change constantly with the model, there are diminishing returns to this.

However, when you start writing code that writes other code using string concatenation, big-picture wise I think you are doing it wrong. Look at HTML and how it has developed towards client heavy apps as other example. Encoding is hard, dangerous stuff, and having a library do it for you (like the w3c DOM APIs, or higher abstractions like react) can be invaluable and can make the difference between spaghetti code and gorgeously understandable functional statements.

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

#312

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

pknopf wrote: post #258

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

There's a middle ground. Micro ORMs.

A micro ORM is just an ORM, written well and modularly. It isn't a middle ground - it's choosing to use a well written library.

A lot of people conflate ORM's leaking because of poor designed library with ORM being a bad abstraction in general.

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

#313

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

bob1029 wrote: post #51

Swapping from EF6 to Dapper was one of the best choices we ever made with our project stack. It is so relieving to be able to hand-tune queries and transactions now. Initially, we were sold on the apparent simplicity of EF6, but as with many things there is a cost for an abstraction like this. In our case, the performance penalties and opaqueness were dealbreakers after a while. We saw an average speedup of 10x on al…

If I was starting from scratch I would probably use an micro ORM like dapper or in my case I have experience with Petapoco.

There are so many "gotchas" to using EF that I'm not sure if was worth using to begin with (for a complex project at least). 8 years into developing and maintaining a huge ecommerce platform built on EF I think if I started over I would probably not use EF.

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

#314

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

daenz wrote: post #141

wvenable wrote: post #113

Earlier quoted context omitted.

Creating an ORM model is so simple the only time I've even given it a second thought is when composing this reply. It's no more difficult than building tables by hand. There isn't any extra work that you wouldn't also have to do when not using an ORM.

cursor.execute(""" UPDATE employees INNER JOIN merits ON employees.performance = merits.performance SET salary = salary + salary * percentage; """) Please show me how much simpler and fewer lines that would be in ORM code + model definitions.

  $db->employees->update({
    salary => $Q{salary} + $Q{salary} * $Q{merit}{percentage}
  });

Not that much simpler in that case, but at least lets you define the JOIN once rather than repeating it per-query.

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

#315

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

725686 wrote: post #37

Each time I see someone complain about ORMs I remember Greenspun's tenth rule[1], which adapted to ORM would be: "Any sufficiently complicated program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a decent ORM." ORMs are hard for a reason. Using an ORM doesn't mean you can't or shouldn't use plain SQL where the situation calls for it. You can mix and match perfectly fine. [1] ht…

> You can mix and match perfectly fine.

Thank you!

This seems like one of those topics where people often feel the need to pick a side for some reason. I've often heard criticism to the effect of, "people only use ORMs because they don't know SQL. Learn SQL!" It's seemingly impossible to convince these people that ORMs are fantastic for reducing boilerplate code and they can coexist right next to raw SQL for problems gnarlier than "select all foo where bar equals baz."

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

#316

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

JesseAldridge wrote: post #227

This was my position for a while. ORMs introduce a layer of magic which obscures what's actually going on under the hood. I decided I would just make raw SQL queries and handle mapping data explicitly. I quickly ended up with a lot of duplicated code. So then I thought, "Well ok, I should add a bit of abstraction on top of this..." I started coding some simple functions to help map the tabular data to objects. One th…

Views are another way to gain reuse.

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

#317

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

2014

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

#318

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

ORM is like a regex. When you use it, you've got two problems. The problem with having two problems is that we love solving problems! Yay OCD! So if an ORM doesn't let us do something, instead of just getting the work done with a couple of quoted SQL strings, we try bending the ORM to our will. I know I've done this with the entity framework. And when we do that, the perpetual debate starts all over again.

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

#319

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

nurettin wrote: post #318

ORM is like a regex. When you use it, you've got two problems. The problem with having two problems is that we love solving problems! Yay OCD! So if an ORM doesn't let us do something, instead of just getting the work done with a couple of quoted SQL strings, we try bending the ORM to our will. I know I've done this with the entity framework. And when we do that, the perpetual debate starts all over again.

Why do I have two problems if I use a regex? "Programming Perl" and "Mastering Regular Expressions" were what drew me into programming in the early 2000s. Whilst ORMs are optional regular expressions are not so I don't get your point.

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

#320

Post by ratww » Sat, Sep 21, 2019, 1:51 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.

But I'm agreeing with you in all those points, like the sibling post said. I actually used OrmLite myself in some projects.