Hacker News Reader

Comment by roel_v | Hacker News Reader

I get why people hate on ORM's, but let's not throw out the baby with the bathwater here - I don't want to go back to the time where you had to write object definitions for each table the database, and manually sync them. Nor do I want to manually write trivial 'select name from foo where id=1' queries all day, and do all the plumbing to execute it. So when hating on ORM's and unnecessary abstraction layers, please qualify that with 'ORM's should not try to be too smart' and 'ORM's should provide fall throughs into whatever they're abstracting for non-trivial use cases', and not give people the idea to ditch ORM's all together.

View on HN

> I don't want to go back to the time where you had to write object definitions for each table the database, and manually sync them.

Sure. Though I'd love if ORMs would seal autogenerated classes to prevent inheriting from them, language allowing, or otherwise prevent people from using generated ActiveRecord objects as their business model objects. ORMs should be just for creating an OO view into relational storage. They should not be running business logic. I know that people worry about having to write another set of classes just to wrap the ORM ones, but really, sooner or later (usually sooner) your business logic abstractions will stop mapping 1:1 to storage needs, and then you'll be wishing you had that extra layer of separation.

Or, in other words, treat ORMs as a more verbose and somewhat-compile-time-checked SQL. Nothing more.

I've had that problem, but frankly it was easier to make an hybrid (mostly ActiveRecord with a few "weird" classes that delegated their own storage) than to write a full Data Mapper layer.

Also, ORMs do more than replace a SQL statement. They compose together so when you have code like:

    person.orders.first

And you change your database to make an intermediary table when business needs change and you need multiple people to be associated with an order you don't need to change the above line of code, you just call a class method in person and everything continues to work. It only gets more powerful with scopes and other things. I still drop into SQL, but usually when I'm doing data analysis, not normal business logic.

Why not make that a view or a stored procedure instead of keeping it as the ORM layer in the application code?

If you use this convenient syntax in many places, replacing it with views could result in hundreds of extra views in the database. Then you would have to maintain them whenever something changes.

There definitely is a reasonable middle ground. The best ORMs I have dealt with provide straightforward paths for simple queries and then let you drop to raw SQL for complex/performance critical stuff.

"Make simple things simple and complex things possible" - worth putting this placard on every ORM/API/DSL/GUI developer's desk.

I wrote almost that exact line in my blog post on the topic: "So a better ORM should make the simple things easy, and the hard things possible." https://blog.dieselpoint.com/a-minimalist-good-enough-approa...

Nor do I want to manually write trivial 'select name from foo where id=1'

You don't have too. SQL is brilliant for writing queries that generate repetitive, standard SQL queries.

Provided that the database vendor documents the system tables.

> const selectBy = (table, column, value) => db.query(`SELECT * FROM :table WHERE :column = :value`, {table, column, value})

> const selectOneBy = (table, column, value) => { const res = selectBy(table, column, value); return res && res.shift() }

Two or three lines gives you about 80% of the value in any ORM and avoids the -20% value found in the other 100k LOC.

> Two or three lines gives you about 80% of the value in any ORM and avoids the -20% value found in the other 100k LOC.

I have a hard time believing this when the two lines above are obviously wrong. You can't use :column to escape the name of a column in SQL. So your code has to protect it, which is not easy if you wan't to be portable. MySQL will generally use `column` but may be configured to use the standard "column".

Anyway, selectAllBy() and selectOneBy() are not enough to be confortable. I appreciate the static completion in Something.find({id: 1}).complete, the relative queries like Post.find({id: 1}).author, and many other things that help against typos, help code faster and make the code more readable.

I agree with the OP that fallthroughs are much needed, because writing custom SQL is sometimes simpler, and sometimes much more performant. Usually, its mostly about writing SomeModel.findAllBySql() which most ActiveRecord implementations provide.

Reply on news.ycombinator.com