Hacker News Reader

Comment by alain_gilbert | Hacker News Reader

I never understood why people are so stubborn about hating on orm.

For example I'm familiar with https://gorm.io and it does save me a lot of time and useless boilerplate.

And guess what, if I ever need to make a complex query, I also happen to know SQL, and I'm just going to make a "raw" query https://gorm.io/docs/sql_builder.html#Raw-SQL and be done with it.

It's not all that hard.

edit:

the other common complaint usually is: "but I don't know what query the orm is going to make..."

Use "Debug" https://gorm.io/docs/session.html#Debug and it will print out exactly what query it's making. Not happy with it? Make a raw query.

View on HN

> I never understood why people are so stubborn about hating on orm.

Objects are just bad abstractions for representing database interactions. They never map cleanly and any attempt to cover up the incoherence introduces further problems.

Avoiding boilerplate is understandable, but typed schemas and queries exist without hauling in a full ORM.

Of course you can pump out a lot of SQL very quickly with ORMs. There's a lot positive to say about this approach! But you don't tend to end up with code where you can easily tell what's going on.

> Objects are just bad abstractions for representing database interactions.

But they're excellent abstractions for business entities.

> Of course you can pump out a lot of SQL very quickly with ORMs. There's a lot positive to say about this approach! But you don't tend to end up with code where you can easily tell what's going on.

15 years building up massive apps with Django and SQLAlchemy and this has never been a problem.

> 15 years building up massive apps with Django and SQLAlchemy and this has never been a problem.

I guarantee you it is if the reader isn't already intimately familiar with SQLAlchemy.

If your job literally entails using a database abstraction and you can't arse yourself into learning said abstraction then it's a skills issue, just as much as people who want to use ORMs without learning SQL.

I can't speak to SQLAlchemy itself, but ActiveRecord (which I'm sure has both shared and unshared issues) still imposes a high maintenance burden with a small team of highly-skilled developers, both on the performance front and the validating-changes front. I, personally, find it very annoying to read, having to hop around an object hierarchy just to figure out what kind of query is generated and what kind of logic is "silently" added to the query somewhere in said object hierarchy (or, god forbid, mixins/monkey-patching).

You definitely make good points, and all my issues are over-comable with time and effort and knowing which tricks to use, so this truly is a matter of opinion and taste. I'm just pointing out that the idea that this produces more readable code seems far from obvious.

IMHO your critiques have more to do with Ruby's promotion of class hierarchies and the fact that ActiveRecord requires inspecting a DB to infer what's going on and Rail's abuse of monkeypatching.

I think it's worth giving SQLAlchemy a try if you're writing a Python app. I've worked with most of the popular ones in Python/JS/Rust, and it's the only one I haven't had to fight with.

I'm back to using bespoke query builders and raw SQL since I don't use Python much anymore, but sometimes miss the syntax and migration system.

Reply on news.ycombinator.com