Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

To ORM or Not to ORM

eli.thegreenplace.net

Post reply on HN
Print view View original

131–140 of 300 posts

Re: To ORM or Not to ORM

#131

Post by hcho »

tmefq wrote: post #123
bunderbunder wrote: post #97

I've come to a couple conclusions, over the years. First, when you get down to it, the most-valued feature of ORMs is not the "writing queries in some language other than SQL" feature, it's the "not having to write a mess of mapping code" feature. Second, the biggest drawbacks to ORMs all derive from the "writing queries in some language other than SQL" feature. Fortunately, there are tools out there that solve the "…

Well said. I bitterly hated sqlalchemy because many times I knew perfectly well how to write a query in plain sql but for the life of me I couldn't figure out how to write the same query using the sqlalchemy language.

Doesn't alchemy have an execute method, to which you can pass a raw sql?

Re: To ORM or Not to ORM

#132

Post by idoubtit »

philwelch wrote: post #101

The ORM discussion reminds me of something Rich Hickey said in his talk, “Simple Made Easy”. He distinguished between “simple” (when a system is inherently low in complexity) and “easy” (when a system is made more complex so it is theoretically easier to use). ORM’s are easy, but not simple. If your system uses a relational database but not an ORM, you have to understand your particular database and also SQL to under…

> ORM's are easy but not simple.

ORM libraries may not be simple, but what matters is the code that uses them.

My experience was that the main code was often easier and simpler. Easier because small tasks are made easy. Simpler because it makes the code more consistent: for instance, once you know the ORM, you don't have to deal with hundreds of specific cases that insert or update various records.

Promoting stored procedures as an alternative to the complexity of an ORM seems strange to me. They still have to be carefully written like any raw SQL. There is no canonical way to keep them in sync with the code. They are vendor-specific. As far as I know, you need to learn specific tools to debug them or to analyze their performance.

Re: To ORM or Not to ORM

#133

Post by btilly »

polygotdomain wrote: post #125
JamesBarney wrote: post #120

Earlier quoted context omitted.

Not to mention code reuse. Say for instance we have one query that finds eligible bachelors near me and another that finds newly eligible bachelors. We need two queries but they both rely on the same underlying domain concept of "eligible bachelors". In entity framework it's easy to save that as an expression that can be reused in multiple places. It's hard to do that in sql in a maintainable way. Not to mention refa…

> It's hard to do that in sql in a maintainable way Views

I have spent enough of my life untangling a mess of views that create performance problems to doubt that views are maintainable.

Also, there is usually no good solution for keeping the database in sync with code releases. With the result that database+code change synchronization tends to be a source of deployment complexity.

Keeping the logic in one place is better than the alternative. And of the two, the tools to manage source control are better.

Re: To ORM or Not to ORM

#134

Post by jtfairbank »

0x70dd wrote: post #21

I've wanted to like ORMs but they always get in the away as requirements start to get more complex. On the other hand, I like writing in plain SQL, but that's often hard to comprehend by other people - you cannot just glance through to know what's happening under hood. I find Ecto to be the perfect balance of expressiveness, flexibility and clarity. In fact it's the single reason to have picked up Elixir.

Have to agree. been really enjoying Elixir / Ecto / Phoenix.

I find Ecto lets me be as expressive as I need to with Queries, and handles the mapping into models very well for the 90% of easy cases that I need it to.

Re: To ORM or Not to ORM

#135

Post by zackb »

bunderbunder wrote: post #97

I've come to a couple conclusions, over the years. First, when you get down to it, the most-valued feature of ORMs is not the "writing queries in some language other than SQL" feature, it's the "not having to write a mess of mapping code" feature. Second, the biggest drawbacks to ORMs all derive from the "writing queries in some language other than SQL" feature. Fortunately, there are tools out there that solve the "…

I've come to the same conclusion, over the years. In the java/groovy/scala world I've written my own a couple times but have come to the conclusion JDBi [1] hits the sweet spot.

1. http://jdbi.org

Re: To ORM or Not to ORM

#136

Post by wyattjoh »

mattwad wrote: post #50
wvenable wrote: post #42

Earlier quoted context omitted.

The real third approach is that you can safely pretend the database is object-oriented for manipulation and simple lists and still use SQL for complex queries. Most ORMs let you safely mix and match both methods easily. This ORM or not ORM is the wrong question. Use an ORM to save you headaches where it's appropriate and use direct SQL when it's not.

I use this approach with Mongoose in Node.JS. If you want to update a user document, we always query the entire document, set the field, and call .save(). This triggers all kinds of very useful validation hooks and is easy to think about. But if you want to find a series of users, or build an API for a specific front-end form, I've found the ORM just gets in the way, and we have not had any trouble writing db queries…

We used to use Mongoose in our project[0], but found that at the volumes of interactions we were dealing with, it was orders of magnitude faster to just use the raw Node.JS driver.

[0]: https://github.com/coralproject/talk/tree/next

Re: To ORM or Not to ORM

#137

Post by jeltz »

chaostheory wrote: post #40
ordinaryperson wrote: post #3

Sample size one 1 but ORM drives me crazy. Why can't we just use SQL? How does it save time when I have to learn the ORM language, which probably has a lot less support and users? The OP here says it "reduces boilerplate" -- rarely have I created an application and thought its biggest problem was too much boilerplate. But everyone at work loves them so I must be wrong somehow.

Have you ever tried it? Your coworkers are right. It also helps you avoid common mistakes like SQL injection. When the ORM doesn't work for a specific case, they usually have ways where you can override the ORM and use your own SQL calls. Virtually every major, popular ORM does this across different languages (can personally confirm with Ruby, Java, & Python ORMs - confident that JS ones support it too).

That is orthogonal. There are ORMs which make SQL injection easy and there are those which make it hard, just as for SQL connector libraries.

This is a matter of interface design.

Re: To ORM or Not to ORM

#138

Post by alkonaut »

I quite like the middle ground of micro orm. Gets rid of the trivial boilerplate like populating fields from query results, and still offers any custom queries.

Re: To ORM or Not to ORM

#139

Post by dragonwriter »

cryptonector wrote: post #9
kasey_junk wrote: post #2

One thing I really miss from the JVM world was something like jOOQ. I don't want an ORM (like specifically the object relational mapping stuff) for most of my use cases but I do want an abstraction above text for interacting with SQL. gorm's sql builder is alright but something better would be really nice.

I don't even want an abstraction for building SQL unless I need to build queries dynamically from some other (presumably simpler) query language. Put all the SQL in .sql files and make all queries parametrized. Or wrap all queries in VIEWs or functions at the RDBMS. This makes maintenance much easier.

> Or wrap all queries in VIEWs or functions at the RDBMS.

This is like the oldest best practice for RDBMS use, for security, and for decoupling consuming apps from each other and the DBs low level implementation (so that app views and base tables can evolve independently to the extent possible), and for maintainability: all app access to the DB should be through views adapted to the apps needs.

Re: To ORM or Not to ORM

#140

Post by rodmena »

Of course I will never use ORM again. Sqlalchemy made my life so miserable that I felt I am the only stupid person in the entire planet. What ORM guys don't think is that SQL IS NOT OBJECT ORIENTED. Why the hell you want to pretend something completely fake?

The problem does not end here, Using ORM make you think object orient which the worst corrosive idea since the dawn of computer science. It made you code like spaghetti.

You read your code 90% of the time and you write code only 10% of the time, that's why clean functional code will result to better software.

Post reply on HN