Is ORM still the “Vietnam of Computer Science”?

Question

I read this post last night, and I noticed it was from 2006. I could go either way on the ORM, database thing, but I was just wondering if everything bad Jeff said about OR

Answer 1

Jeffs article links through to Ted Newards article. If you are into the details then you need to look there:

1. original - http://blogs.tedneward.com/post/the-vietnam-of-computer-science/

2. followup - http://blogs.tedneward.com/post/thoughts-on-vietnam-commentary/

Of Ted's original points I have it as:

• 1 was wrong (Identity)
• 2 of them solved (Partial objects and N + 1)
• 2 are debatable (Dual schema / shared schema).

Disclaimer: I'm the author of Ebean ORM so I'll reference that for the various 'solutions' to the issues raised.

Ted's original points (distilled because it's really wordy):

1. Partial Object problem.

Always solvable. Ebean ORM made partial objects fundemental to it's query language and all internals. JPQL didn't make this a priority to it's more a problem there unfortunately.

• Refer: http://ebean-orm.github.io/docs/query/partialobjects

2. N + 1 (Ted's Load time paradox)

Always solvable. Should have been written as 1 + N / batchSize but it is more interesting than that (per path, need to take into account SQL paging, avoid sql cartesian product). Some ORM's make a right mess of this unfortunately and that brings ORM in general into disrepute. Some ORM's are ok until you hit a level of complexity (like OneToMany inside OneToMany inside OneToMany).

• Refer: http://ebean-orm.github.io/docs/query/nplus1

Just to up the ante here ORM's can profile the object graph use and automatically optimise the query (only fetching what is needed, defining fetch paths to optimise for N + 1 etc).

• Refer: http://ebean-orm.github.io/docs/query/autotune

This automatic ORM query optimisation idea came out of the University of Texas (using Hibernate). It was included as part of Ebean ORM in 2008 so it's been around for a while now.

• Refer: https://en.wikipedia.org/wiki/AutoFetch

3. Identity

Ted cracks on about a mismatch on identity and concurrency. This point is misplaced as ORMs (well, all the ones I know) go about this aspect in exactly the same manor as the prior client/server tools and specifically ORM's are providing a SNAPSHOT view of part of the database to the application. There was never a problem here but ORM implementations could get themselves into strife with an over reliance on hashCode()/equals() for example.

4. Dual schema problem

This is debatable. If the organisation allows then the ORM can provide a DIFF/SQL script to the schema and that is run by FlywayDB/Liquibase etc. If organisations don't allow that this might still be an issue to some extent.

5. DB Refactoring / Shared schema

This is debatable. DB design/normalisation folks would argue that the DB design should get to 4NF and that means any refactoring should solely be additive (denormalisation, adding columns/tables) and not breaking changes. People who don't believe in normalisation will be going nuts worried about shared schema.