

Taking a Step Back from ORMs - ratsbane
http://thoughts.davisjeff.com/2012/02/26/taking-a-step-back-from-orms/

======
Tinned_Tuna
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).

~~~
bunderbunder
_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?

------
ceyhunkazel
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...](http://scala.playframework.org/documentation/scala-0.9.1/anorm)

------
steveklbnf
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.

------
dmmalam
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.

