Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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?
It’s an object model for an algebra of relational query operators.
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 anamed_scope". And, whaddayaknow: both were written by the same guy.No, it uses objects as queries.
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".)
Yes. For example, as I mentioned above, it is much easier to construct more complex queries from simpler parts.
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.
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.