3 ms·

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

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 15y ago
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?

bunderbunder 15y ago

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?