Hacker News Reader

Comment by forgetfulness | Hacker News Reader

ORMs when you have to do the most basic selects and joins, with naive pagination: look at how easy it is, it's magic!

Also ORMs when you have to do anything more complex, specially if they involve aggregations: welcome to my awkward undocumented APIs, you now embark on a journey through hard-to-search-through class definitions and source dives that you'll share with every programmer that will touch your code in the future.

View on HN

Every ORM I've ever used has some raw SQL escape hatch you can use when you hit that edgecase. For the 90% of DB access that really is simple, ORMs are a pleasure. For that other 10%, if your alternative is raw SQL, just use the escape hatch and you're not worse off than if you had skipped the ORM.

You can also map or redirect the objects to database views

Ooh, database views! What would be next?? Permissions? Triggers?? Stored procedures??

Go shove your views up yours, you maniac!

/s, except for way many more ORM lovers than you think.

I too love debugging stored procs and other database-oriented-programming constructs because somebody was scared to write code

Wayyyy back in the day, after the dotcom crash, I got moved from a SWE role in my company to the consulting (customer implementation) side to try to bring more rigor to their process. One of the first things I did was replace a several thousand line stored procedure full of pivots, transforms, cursors, etc. with a few hundred lines of code. As a bonus, performance improved by a couple orders of magnitude as well.

Knowing what to process in memory, what to delegate to the database, to the datawarehouses, or other heavyweight data-processing engines like Spark, is its own subfield, data engineering.

Finding data engineers that can actually do it will become difficult in just a bit, as there's a goldrush to take on that role, and lots of people want in with some rudimentary knowledge of SQL and Python.

Anyway, I'm always suspicious of people advocating for stored procedures, because those are version controlled if you're lucky, and I've yet to see them subject to automated testing.

Random google search for "migrations stored procedures" https://stackoverflow.com/questions/14139445/code-first-migr... shows that EF6 already supports them.

And pgTap as an example of testing them https://pgtap.org/ .

What I'm suspicious is that, having seen untested stored procedures, you haven't bothered to try unit test them. I mean, you can do a lot with BEGIN; set db in good state; call procedure; ROLLBACK; but you have to try.

That's an unmaintained Perl library, I highly doubt it sees significant use.

I haven't seen untested stored procedures in years, because I don't use them, no team I've been in uses them.

Complex prepared statements, that's common, but stored procedures, no.

What do you think stored procedures are written in if not code? Some of them are written in even C++ (I've done plenty myself).

I understand the sentiment but there is not anything inherently wrong with a stored procedure. If they came out today we'd probably call it edge computing.

Harder to test and debug than code.

It is actually the exact same level of effort as code as it is code.

If you mean stored procedures are harder to test than something like ORM in Django than that is just a huge misunderstanding of how you properly write stored procedures while also not understanding how hard it is to actually test a lot of ORM logic.

You dont test orm logic, it is being done by orm makers.

You test your app.

Also, not abusing database and writing code doesnt mean lets get deep into the ORMs madness.

You can do not write logic in db and still write raw sql

"You dont test orm logic" this explains a lot of your confusion

Has the tech changed significantly, or are triggers still an impediment to replication?

Plenty of people who use ORMs have absolutely no ability to even begin to use the "raw SQL escape hatch." People who do know SQL know exactly how their ORM performs, and know exactly when and how not to use it.

Yep. But also, I've met plenty of people that know SQL but have an aversion to using inline SQL escape hatches out of purity.

One fun case I witnessed involved a junior developer adding the desired/resulting SQL as a comment to every complicated Rails AREL queries, so that people could know what the query was doing.

Then, after seeing that, one of the tech leads determined that EVERY query should have SQL on top of it, for consistency, even things like User.all had the `SELECT * FROM users` on top.

In hindsight it's funny but it was a terrible team and a terrible software.

Reply on news.ycombinator.com