What exactly is Arel in Rails 3.0?

Question

I understand that it is a replacement for ActiveRecord and that it uses objects instead of queries.

But...

why is this better?

will objects/queries be "easier" to create?

will it lead to more efficient SQL queries?

will it be compatible with all major DBs? - I assume it will.

will it be easier/harder to use with stored procedures?

Answer 1

What exactly is Arel in Rails 3.0?

It's an object model for an algebra of relational query operators.

I understand that it is a replacement for ActiveRecord

No, it isn't. It's a replacement for hand-crafting SQL queries in strings. It is a common query layer that underlies ActiveRecord, but it can also be used as an underpinning for DataMapper, for example.

If it is a replacement for anything, it's a replacement for Ambition. Or, you can think of it as a Ruby version of the LINQ standard query operators or Python's SQLAlchemy. (In fact, the author explicitly cites both LINQ and SQLAlchemy as inspirations.)

Or, you can see it as a replacement for named_scopes. In fact, ARel is pretty much the realization of the idea that "every query is a named_scope". And, whaddayaknow: both were written by the same guy.

and that it uses objects instead of queries.

No, it uses objects as queries.

why is this better?

Ruby is an object-oriented language, not a string-oriented language. For that reason alone, it makes sense to represent queries as objects instead of strings. Building a proper object model for queries instead of using strings for everything gives you pretty much the same benefits that building a proper object model for an accounting system instead of using strings for everything gives you.

Another big advantage is that ARel implements an actual algebra of query operators. In other words, ARel knows about the mathematical rules for constructing and composing queries. If you concatenate two strings, each of which contains a valid SQL query, the result is probably not going to be a valid SQL query. Or, even worse, it is a valid SQL query, but one that doesn't make sense, or that does something totally different from what you think it does. This can never happen with ARel. (This is what the article I link to below means with "closed under composition".)

will objects/queries be "easier" to create?

Yes. For example, as I mentioned above, it is much easier to construct more complex queries from simpler parts.

will it lead to more efficient SQL queries?

Yes. The fact that ARel has a proper object model for the queries means that it can perform optimizations on those queries long before it ever generates an actual SQL query.

will it be compatible with all major DBs? - I assume it will.

Yes. In fact, I always talked about SQL above, but actually a relational query algebra can generate queries for pretty much everything. Again, see LINQ or Ambition as examples: both can query SQL, LDAP, ActiveResource, CouchDB, Amazon, Google, … all with the same syntax.

Perhaps the best discussion as to what ARel is and why Nick Kallen wrote is the aptly named article Why Arel? by Nick Kallen himself. Note: the article contains some mild mathematical and computer science jargon, but that is exactly the point: ARel has some strong foundations in mathematics and computer science, those foundations are what give it its powerful properties.