I'm going to make an argument here, and you might disagree but that's fine:
If you don't understand the purpose of an ORM, you haven't worked on a sufficiently large enough software project or don't fully understand what the definition of an ORM is.
If you need to write a report of any fashion, do not use an ORM. You can help write the report with your ORM of choice, but at some point you need to get down to the language that the database speaks because you're doing the kind of set mathematics that ORMs aren't made for.
BUT, if you need to add a user permission, and you're doing anything other than:
If your object model at some point gets persisted into a database, then you're going to need to write code to (load from/save to) the database. At which point, if it walks like a duck, and quacks like a duck...
>> In other words, ORMs are at their most useful when solving the least challenging problems. To which we must ask: why bother?
1. I disagree with your assertion. Ruby's ActiveRecord has scopes that make it very easy to compose complex queries from pieces; start with a simple query, then conditionally add clauses like where, having, joins, group, order, etc. I'm looking at code right now where mixing and matching clauses like that was crucial. It would have been a nightmare to do in raw SQL.
2. Even if you were right, "least challenging" != "least annoying." Washing clothes is a trivial problem, but I'm glad to have a machine do it. Same for writing the same boilerplate SQL 30 times a day.
