3 ms·

The current Ruby ActiveRecord is based on Arel, which is a relational algebra. Everything in Arel is necessarily set-oriented and the results of expressions in

The current Ruby ActiveRecord is based on Arel, which is a relational algebra. Everything in Arel is necessarily set-oriented and the results of expressions in the ActiveRecord ORM language are the exact objects that went into the set, as long as they are truly set operations. Same thing with aggregate functions and grouping. Why do you expect the resulting object of an aggregate over source objects to have the same kinds of methods? That makes no sense at all. What should the 'name' of a record return when you've aggregated over the salary of many employees? That makes no sense in the original relational algebra, whether expressed in SQL or ORM, either. Aggregating is not a set operation and there part of the false dichotomy comes in: SQL isn't quite as pure and easy to understand as ORM opponents would have you believe.

fauigerzigerk 15y ago
Exactly, encapsulation as a combination of data and methods makes no sense if data is transformed, joined in different ways, grouped, etc. Some methods have to become invalid. Others, like accessors, may still be logically valid but are lost because they are linked inextricably to a class type even though they may depend only on the attribute value itself. The goal of a query is not to process sets of objects. The goal is to answer a question. The ORM gives you two choices. Either limit yourself to answers that can be expressed as objects of existing classes or get something that is fundamentally different from all other domain objects - a generic tuple of values. You lose the homogenous, recursive transformation capability that the relational model provides. In terms of simplicity, I suggest you take a few queries involving joins, group by, having and aggregates and translate them to procedural code. I've done that a lot. It's very eye opening. Functional languages using homogenous data structures like lists or generalized sequences can be similarily productive for data that fits into memory. That is a more and more viable alternative to SQL in my view, but OO systsms and querying/transformation just clash badly.

fauigerzigerk 15y ago

Exactly, encapsulation as a combination of data and methods makes no sense if data is transformed, joined in different ways, grouped, etc. Some methods have to become invalid. Others, like accessors, may still be logically valid but are lost because they are linked inextricably to a class type even though they may depend only on the attribute value itself. The goal of a query is not to process sets of objects. The goal is to answer a question. The ORM gives you two choices. Either limit yourself to answers that can be expressed as objects of existing classes or get something that is fundamentally different from all other domain objects - a generic tuple of values. You lose the homogenous, recursive transformation capability that the relational model provides. In terms of simplicity, I suggest you take a few queries involving joins, group by, having and aggregates and translate them to procedural code. I've done that a lot. It's very eye opening. Functional languages using homogenous data structures like lists or generalized sequences can be similarily productive for data that fits into memory. That is a more and more viable alternative to SQL in my view, but OO systsms and querying/transformation just clash badly.