People Managing to Correctly Spell “Moron” in a Blog Comment

The notorious ORM pro / con discussion heavily amuses me. I always find it very funny when people have passionate discussions about which solution is better, rather than discussing about which solution is better suited for the problem at hand. In the case of ORMs vs. plain SQL, obviously, no solution is simply better as both techniques have their merits. When comparing ORMs with jOOQ, I think that this page summarises it pretty well:
http://www.hibernate-alternative.com

Now, this article and most specifically, one answer is hilarious:
http://java.dzone.com/articles/defense-hand-coded-sql

While the article’s author is already asking for trouble, check out this one particular answer. I love it when people manage to correctly spell “moron”:

People who handwrite SQL are invariably morons.

Here’s what you miss out when using a good ORM with generated mappings:

– Automatic first and second level caching

– Guaranteed consistency between code and database structure. Change the database? Regenerate pojo’s -> compile errors until code adheres to database structure.

– True vendor independence. Yes, I’m switching between six different db’s in our products with zero issues.

– I work with objects, not relation sets. That kinda makes sense in an oop language.

– Build-in query languages in decent ORMs are much more productive and, again, vendor independent.

– Any decent ORM understands and injects vendor specific query hints better than you.

Also, get a clue.

Here’s my adequate reply to the above:

OK, now this was amusing 🙂

– Automatic first and second level caching

This, obviously, is utterly impossible outside the world of ORMs.

– Guaranteed consistency between code and database structure. Change the database? Regenerate pojo’s -> compile errors until code adheres to database structure.

True. No one has ever written a code generator before it was added to Hibernate.

– I work with objects, not relation sets. That kinda makes sense in an oop language

… which your DBA will probably always agree with. Remember to remind your manager why he bought that 1M$ Oracle license, when you run N+1 selects for fetching your OOP objects.

– Build-in query languages in decent ORMs are much more productive and, again, vendor independent.

Of course, there is always a black / white answer to “productivity”- questions. Like, how productively you can express a SQL:2003 MERGE statement with HQL. Or, how productively you can calculate a running total involving window functions, or maybe, recursive SQL with HQL.

– Any decent ORM understands and injects vendor specific query hints better than you.

That is indeed an amazing theory, which I was utterly unaware of.

The eternal debate between ORM lovers and haters. Mankind has always been this stupid.  Like the AC vs. DC discussion between Nikola Tesla and Thomas Edison

And, Eclipse will totally win over IntelliJ! 😉

11 thoughts on “People Managing to Correctly Spell “Moron” in a Blog Comment

  1. I’ve seen many projects which have bad performance and did use Hibernate or JDO. I hate those technologies (along with JPA).

    After writing thousands of line of JDBC code I’ve realized how it could be done properly.

    After analyzing dozens of hibernate alternatives, I couldn’t find the one I liked.

    Finally I made fast java ORM framework and opensourced it at:
    https://code.google.com/p/fjorm/

    It is quite similar to ActiveJDBC, but I like mine more.

    Hope someone might like it. I’d certainly enjoy if Lukas reviews it, no matter if review is bad ;-). Although I enjoy this blog (big fan), I’m not fan of jooq :-(.

    • After writing thousands of line of JDBC code I’ve realized how it could be done properly. After analyzing dozens of hibernate alternatives, I couldn’t find the one I liked.

      That’s how most new ORMs are born. Is that a good or a bad sign for your tool? 🙂

      Although I enjoy this blog (big fan), I’m not fan of jooq

      Thanks for the first. What made you say the latter? From what I can see on your documentation wiki, jOOQ pretty much covers all features fjorm claims to have, although, after downloading, I mostly see throwing of UnsupportedOperationException. How does it / will it eventually add value?

      • Regarding jooq:

        create.select(AUTHOR.FIRST_NAME, AUTHOR.LAST_NAME, count())
        .from(AUTHOR)

        This looks weird code, as AUTHOR is somewhere defined as variable. (most likely it is generated from the database as class with fields FIRST_NAME, etc.)

        BTW, documentation doesn’t not specify what create method returns

        Regarding UnsupportedOperationException in fjorm code:
        – mostly this happens when using LazyCache or FullCache since some methods are not implemented here
        – I implement something when I need it for my projects
        – StandardDao (standard implementation) implements all methods

        I don’t know how did you see that (probably looking in the code, which was nice of you). I’d check tomorrow jooq code to send you few comments (I’ll put it in my TODO list).

  2. OK, now I understand jooq better and I must agree that I like it much more.

    It contains a lot of code to support various SQL dialects. It is not mini project like fjorm.

    There is no need to hook fjorm pojo into jooq at this time, thanks.

    The choice someone might make is for example jooq example:
    create.select()
    .from(AUTHOR.as(“a”))
    .join(BOOK.as(“b”)).on(a.ID.equal(b.AUTHOR_ID))
    .where(a.YEAR_OF_BIRTH.greaterThan(1920)
    .and(a.FIRST_NAME.equal(“Paulo”)))
    .orderBy(b.TITLE)
    .fetch();

    in fjorm would be:
    authorDao.read(“inner join book b on author.id = b.author_id where a.year_of_birth >= 1920 and a.first_name = ‘Paulo’ order by b.title”);

    so my preference over the second one is that translating SQL I’d write into JOOQ syntax makes me some effort, I’d first in the beginning would need to write SQL and then JOOQ from that one.

    I look tomorrow more into JOOQ code and try to read better manual (RTFM, RTFM Luke)

    Thanks

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s