In my experience ORM always shoots you in the foot when your use case exceeds what an ORM can provide. ActiveRecord has been a terrible mess for us because the facade masks the underlying behavior (transactional behavior) or often doesn't do what it advertises (commit hooks, timestamps, auto-increment).
ORM is great for startups trying to build out an MVP, but beyond that scale it's an anti-pattern.
The best solution I've ever seen is jOOQ, which is essentially typified SQL. Your queries have to pass compilation, but the DSL is essentially SQL itself. It's an added layer of security yet still manages to feel like it's easier to write than raw SQL.
More languages need a jOOQ. It's so good that I'd choose Java just for the ability to leverage jOOQ.
I came here to say that any article discussing the benefits/downsides of ORMs should include JOOQ. It takes such an interesting spot in the design space: not an ORM, but a super flexible, type-safe query builder with lots of helpers so you dont write more code than necessary.
I work at a place with sort of a homebuilt ActiveRecord system made of generated code. JooQ did all the same mapping and object creation just by inspecting my database with a bunch of boilerplate Maven XML, so I wouldn't have to rely on the homebuilt version of SQL join.
ORM is great for startups trying to build out an MVP, but beyond that scale it's an anti-pattern.
The best solution I've ever seen is jOOQ, which is essentially typified SQL. Your queries have to pass compilation, but the DSL is essentially SQL itself. It's an added layer of security yet still manages to feel like it's easier to write than raw SQL.
More languages need a jOOQ. It's so good that I'd choose Java just for the ability to leverage jOOQ.