It's a very interesting topic but it gets weird when large words ("completely unworkable", "causes huge problems in even small projects", "retrieving whole rows is hugely wasteful", "unfortunately Active Record access patterns break down almost immediately") are used to describe something that doesn't match one's experience at all. I wish we could focus on the Active Record concept itself rather than implementation details or specifics of projects where the pattern has been applied.
The article talks about projection, joins and aggregations, but many projects in Rails that I've seen just don't need those: it's often solved in the application. Yes, it's SUPER SLOW, it loads data just to throw it away again and can break ACID properties, but it generally works -- these applications aren't handling transaction on a stock exchange or controlling a pacemaker. And in the case of Rails' ORM, it's been very easy to do real joins, projections and aggregations when needed, meaning that the Active Record pattern itself hasn't excluded that possibility.
The paragraph about transactions is also a bit weird as it has nothing to do about the Active Record pattern afaics.
Apologies for the word largesse - I should probably have edited out the adjectives (which always cause me a problem) more aggressively.
I actually find that even though these applications aren't running pacemakers that they still don't work. It's really easy to write what is in fact bad algorithm for accessing (eg) shoe size data when you are working on rows only as objects.
I cannot speak (and am not) for the Rails ORM but the problem here is less about some library people use but about the primary affordances being "get this object by id, edit it, and save it back". This is just not right IMO and is the underlying cause of the famous "object-relational mismatch". I suppose I come down on the relational side of that in that I think object access is the problem.
The article talks about projection, joins and aggregations, but many projects in Rails that I've seen just don't need those: it's often solved in the application. Yes, it's SUPER SLOW, it loads data just to throw it away again and can break ACID properties, but it generally works -- these applications aren't handling transaction on a stock exchange or controlling a pacemaker. And in the case of Rails' ORM, it's been very easy to do real joins, projections and aggregations when needed, meaning that the Active Record pattern itself hasn't excluded that possibility.
The paragraph about transactions is also a bit weird as it has nothing to do about the Active Record pattern afaics.