Taking a Step Back from ORMs | Hacker News Reader

Taking a Step Back from ORMs

thoughts.davisjeff.com

18 pointsratsbane5 comments

I would argue that an ORM does get in the way in a good way. A decent ORM can do things such as extra full-text indexing behind the scenes (Thing Hibernate and Lucene) to provide a much better search over almost any database. You only have to tell it to do so (i.e. configuration) and it springs to life.

Similarly, if you decide that you don't like PostgreSQL and want to move to MySQL. You can go through your code and change all of your SQL to match the PostgreSQL dialect. Or (with Hibernate) you change one configuration parameter (the hbm2ddl one) to use the MySQL dialect as opposed to the PostgreSQL one.

Hibernate (I'm using Hibernate a lot, because it's the one I use at work, so I'm quite familiar with it) can also be configured to check the database schema at start, update it to match your models, create a new schema or create a new schema and schedule it all to be dropped when your application terminates. This is useful, because your test configuration can be create-drop, and your live can be validate. When upgrading the live system, you can just redeploy with "upgrade" as the configuration.

In short, ORMs do have a lot of behind the scenes magic going on, but they can also offer developers a heck of a lot. Not to mention that they're thoroughly tried and tested bits of code. Hibernate even has the capacity to take on various transaction managers (Bitronix allows you to do one transaction over two databases, even if those databases are from different vendors).

You can go through your code and change all of your SQL to match the PostgreSQL dialect. Or (with Hibernate) you change one configuration parameter (the hbm2ddl one) to use the MySQL dialect as opposed to the PostgreSQL one.

I hear ease of switching often being given as an advantage of ORMs. What worries me is that this might be code for, "You have to settle for the least common denominator."

For example, in the PostgreSQL/MySQL example: Will Hibernate recognize when it's appropriate to use a common table expression when working with PostgreSQL, and also degrade to something that works with MySQL's feature set when you switch? Or will Hibernate take advantage of MySQL's INSERT IGNORE statement, and happily switch to MERGE if you go over to Oracle?

I agree that using SQL more powerful and easier to debug . Play Framework Anorm transforming result to objects approach is the best approach that I think we do not need to an ORM. http://scala.playframework.org/documentation/scala-0.9.1/ano...

Every ORM should allow for easily seeing the SQL queries which it is generated. With this, a discerning programmer is able to recreate the SQL calls as if it were the application, as well as often do an overview to make sure the SQL calls make sense and are efficient. If one keeps tabs on what is being generated, and understands what's going on behind the scenes, ORMs can be excellent for code readability.

Granted, I do appreciate the commentary and think the best point is that it is important to be able to know how to leverage the tools of your specific DBMS when appropriate. This is a huge thing that is often overlooked with novice programmers who jump into ORMs.

Totally agree. I've done exactly the same with the excellent node_redis driver. A thin layer to remove boilerplate, but still directly fire commands at the DB.

Reply on news.ycombinator.com