I'm not sure if ORMs are an anti-pattern

How does using an object database exclude transactions? Transactions make as much sense for rows in a database as they do for objects in a database or even objects in memory. Atomic object graph mutations are an essential feature of any concurrent system. It just won't work any other way.

The reason to use an ORM instead of an object database is twofold. One, it's safer to use a working database and put some libraries on top of it than it is to write your own database. Do you want to write unit tests for the deadlock detection algorithm? Two, sometimes you're writing an online transaction processing application (99% of web applications) with fixed domain objects, but you want the flexibility to slice-and-dice the data in the future. In that case, an ORM makes your relational database look like an object store to the application (which is exactly what it wants), but it also lets you play with the data in Excel if you want to. The key is not that the data is relational, but that it's in a standard format that other software understands.

Ultimately, there are three kinds of applications that you can write. One is what most software is; the user interacts with the application and generates state along the way and you want to record that state and act upon it. In that case, an object database is perfect; the state is meaningless without the application, so there's no reason to encode the state so as to be meaningful to other applications. The next case is something like this but where the data might be useful outside the application (auditing, reporting, other features). In that case, ORM is exactly what you need. Your application wants objects, but the other things that need the data want it in a database. So you compromise and store it in a database, using an ORM to make the relational database look like an object store to your application. The third case is an application that is not particularly interactive (think credit-card processing network), and you don't need any app-specific state to be preserved. In that case, raw database access is perfect; if all you are doing is INSERT INTO transactions VALUES ('jrockway', 'amazon.com', '19.95'), the ORM is just going to waste your time.

I don't really need the external validation anymore. If people do or don't like some of the tools and techniques that I find useful, it doesn't matter. Their tastes and tolerances and scenarios are often different.

+1 for not just writing to ride on the debate for page views and pointing out the areas of possible discussion.

The assertion is that ORMs are an anti-pattern because it's hopeless to represent data from a relational db as object in an OO language. Obviously, an object or document database maps better to OO languages. My question is, what programming style maps correctly to relational data, other than the obvious answer of SQL?

after blogging this, i found a few example ORM systems which may be interesting to study. I still don't know the answers, but O/R Broker[2] seems the tightest one and it isn't even really an ORM[3].

[1] http://stackoverflow.com/questions/1362748/wanted-good-examp... [2] http://code.google.com/p/orbroker/ [3] http://code.google.com/p/orbroker/wiki/JoinExample

Most of the time: Yes, traditional ORMs are an anti-pattern. If you think you want an ORM, consider an ODB or KVS instead (neither of which are relational).

what is conditions api?