Hacker News Reader

Comment by the_af | Hacker News Reader

The underlying problem is one of O-R impedance mismatch. Going full SQL and getting rid of the ORM is a possible answer, but it has tradeoffs and is not a silver bullet. It might mean re-creating from scratch an in-house, bug-ridden ORM, or ditching OOP idioms from your language, or both.

The author of TFA seems to be going through one of the stages described in "ORM is the Vietnam of Computer Science", an article that should be mandatory reading before one claims to know the solution to this decades old problem.

View on HN

I've found jOOQ to provide the right tradeoffs and flexibilities for ORM vs. SQL. First, it can generate object models of tables from the database in development and therefore doesn't rely on any specific migration tool. These model classes can be used in a conventional ORM fashion, but you also have the option to use jOOQ to build SQL queries.

You can even fetch the results of arbitrary SQL expressions into a model class, which can handle partial population of columns. This allows combining ORM and SQL approaches with some code operating on models where that is natural, but this code can be applied to models which are fetched in alternative fashions when that is more preformat. E.g., fetching records using criteria that involves joins and only selecting relevant columns for the subsequent processing of fetched results.

The jOOQ "DSL" (i.e., Java interfaces and static methods) gives you essentially the full power of SQL without having to rely on external SQL files or stored procedures. (Or even worse strings.) You can even programmatically build these queries. E.g., optionally including different WHERE/HAVING criteria. The jOOQ "DSL" provides a fair amount of compile-time type safety, which isn't possible with external SQL.

jOOQ is great. It brings a lot:

* auto-complete in your IDE when writing queries in jOOQs Java DSL that maps quite naturally to SQL

* type safety. e.g.: migrate after a schema change, re-generate your jOOQ lib and see in your IDE (red underlines) all the place your queries would break using the new schema

* build queries from parts (e.g.: store/manipulate some where clauses in a local variable) w/o any string manipulation

But is has costs:

* generate the jOOQ library from your schema at build time (or everytime the schema changes): increase build time (a little) and complexity (a db needs to be around during builds)

* very small runtime overhead: queries are build at runtime

* one more thing to learn

To me the benefits outweigh the costs (unlike Hibernate, I much agree with the article) and I consider it similar to LINQ on C# while not being some language built in feature with it's own syntax.

Here's the article

http://blogs.tedneward.com/post/the-vietnam-of-computer-scie...

Edit: huh, seems to have got truncated over the years. Here's an archive link

https://web.archive.org/web/20160120004603/https://blogs.ted...

>“ORM is the Vietnam of Computer Science”

In other words it’s a complicated subject with a long and fascinating history, yet Americans will tend to only remember the short, disastrous bit they were directly involved in?

No, the takeaway from Ted Neward, the author of this analogy, is this:

> "Although it may seem trite to say it, Object/Relational Mapping is the Vietnam of Computer Science. It represents a quagmire which starts well, gets more complicated as time passes, and before long entraps its users in a commitment that has no clear demarcation point, no clear win conditions, and no clear exit strategy."

Though I must admit your take is good, too!

I don't believe that to be the case. The vast majority of applications built on top of ORMs design databases so that they are easy to map to. Sure, as soon as you access a database that wasn't designed for the ORM you run into trouble but this is an all or nothing problem. Getting rid of the ORM where it works doesn't actually provide you with a benefit.

> Sure, as soon as you access a database that wasn't designed for the ORM you run into trouble

Don't you mean the reverse? A relational database is never designed "for the ORM" -- ORMs are designed (sometimes poorly, sometimes better) for some databases. The object-relational impedance mismatch problem is well known in software engineering for a reason: OOP and relational databases weren't designed with each other in mind, and in fact, "fight against each other" in many ways. This is the starting point of the Vietnam article -- you can disagree with the analogy, but the impedance mismatch is very real.

Reply on news.ycombinator.com