What exactly is Arel in Rails 3.0?
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?
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.
ARel, is unfortunately tied directly to generating SQL and thus is unsuitable for DataMapper's needs.
The way I would put it is that ARel is an explicit query model for ActiveRecord that generates and optimizes SQL queries for RDBMSes.
DataMapper on the other hand is a genuine mapper for data, and can interface with non-relational data stores already. In the future DataMapper is likely to include a separate library called Veritas, which is intended to provide relational functionality to data sourced from ANY data store, not just RDBMSes.
Arel in Rails 3 makes relation objects where the db isn't queried until you need it. Much more efficient.
It's also more natural (once you get used to it) which is really the great strength of Rails.