ROrobertothais·Aug 9, 2017Submission
Ruby internals: “This is some roflscale crazy stuff”
2 points · Open discussionrails
arel
Ruby2010–2017
rails / arel
arel
A Relational Algebra
12Distinct people
13Mentions
0Explicit recommenders
2KGitHub stars
What to know before exploring
What it is
A Relational Algebra
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year13 dated mentions
Observed mentions: 2010-01-27 03:55:17 UTC to 2017-08-09 20:42:09 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2010 | 2010-01-01 00:00:00 UTC | 2011-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2011 | 2011-01-01 00:00:00 UTC | 2012-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 2 | 1 | 1 |
What Hacker News says
13 sourcesHave you ever seen Arel?
https://github.com/rails/arel
In SQL is 43 years old – Here’s why we still use it todayYeah, I'm planning on killing Arel at some point. I actually want to extract `Relation` to a gem entirely, as it's really not an adequate query builder for what we need in AR.
Also random fun story about Arel not being immutable. We had a bug in 4.1 where basically PG bind params are ordered, but Relation can't actually know the order ahead of time (e.g. because a Relation can be used in a from clause). Turned out actually fixing it was somewhat hard (the "real" fix was eventually https://github.com/rails/arel/commit/590c784a30b13153667f8db...). But as a hack, basically someone took advantage of the fact that `Arel::Nodes::BindParam < SqlLiteral` and `SqlLiteral < String`, and Strings are mutable. So they just ignored the lack of a proper map function, and fiddled with the strings. >_>
Anyway, yeah our AST is fun because Rust's compiler l
Read the rest
ets us set it up so that we can walk it as many times as we need basically for free (because it gets monomorphised and the walking ultimately gets inlined and optimized away)
Yeah, that does sound like exactly what I want. Still has the "conventions" problem I mentioned, but maybe worth it, and common enough that it isn't that big a deal.
To your edit: Ha, I have a PR against arel that is similarly neglected[0]. Maybe an advantage of using a less popular library is that the maintainers aren't so overwhelmed that things get lost in the shuffle!
[0]: https://github.com/rails/arel/pull/320
In Patching Rails Performance> The main problem with raw SQL is that what you really want is a genuine programming language. You almost want programmatic access to the SQL AST, so you can generate syntax as opposed to concatenate strings together. Kind of like a DOM API, but for SQL.
Congratulations, you just described Arel.
I liberally use rails/active_record where it shines (operating on a single record, or writing composable scopes) but very often find myself leveraging Arel (accessible via YourModel.arel_table) to generate a carefully crafted SQL AST.
At my current job we have two gems leveraging this power: "Massive Record", allowing one to perform bulk operations (insert, upsert) on huge lists of records in an efficient way (instantiating hashes instead of full-blown ActiveRecord instances), and "Chains", which allows one to handle authorization at a per-entity
Read the rest
or per-record level with a iptables-like system. There is no way the generated queries could be sanely written by hand, nor as concatenated strings. Arel allows us to build highly dynamic queries while still tuning for performance. Database independence comes as a bonus, and we can easily extend Arel with more nodes, possibly some database specific ones that get selectively added depending on the configured database.
Arel also allows us to write clean and efficient database migrations, where we basically use your typical ActiveRecord faux models merely for datatable reflection to obtain column names and types.
[0]: https://github.com/rails/arel
>With a low level abstraction layer, I can do stuff like already_complicated_query.filter(another_param==5). Or I can write a function that does get_world_trade_aggregate(country="USA", aggregate="average") and it'll generate the right query for me. But then that's not even all, if I have to modify or filter that query further in some other part of the code, in some unexpected way totally doable. It's less often that I have to write a whole new function or duplicate code.
If you're working in Ruby, there's also Arel[1]. I have my complaints, but it seems to be the exact same thing: Composable, programmatic access to SQL from your application code.
[1] https://github.com/rails/arel
In What ORMs have taught me: just learn SQLActiveRecord supports lots of stuff through arel (https://github.com/rails/arel).
Are you sure you understood how to use the full functionality? What was missing (besides CTEs)?
In SQLAlchemy vs Other ORMsI've been running Java and Rails since 2006 in my company (large), we use C# for a small number of desktop applications.
This will come out harsh, but I'm being honest: If you are not willing to fix/adapt/improve the framework you are using, you better not be using ASP.NET also (try a google search on asp.net issues), or any framework at all. In fact, developing larger more complex software might not even be possible without adapting frameworks for your specific problems.
That said, our run so far with Rails and Java (we are still using 2.3!!!):
- We have 38 patches applied to Spring
- 4 patches in apache santuario.
- One security patch on Grizzly (glassfish)
- Rails: One single pull request https://github.com/rails/arel/pull/174
In Rails 3.2.13 - Performance regressions and major bugsAs I'm not on the Rails core team and didn't really pay much attention to their design process, all I can offer is the major rewrite of ActiveRecord from 2 to 3 and, specifically, the introduction of Arel in AR3 had huge implications for the API design.
Specifically, check out the README at https://github.com/rails/arel .. if you're familiar with Rails 2 and earlier, the sorts of things you'll see there probably seem quite alien to you. I believe AR had to change a lot to fit in with this approach to SQL generation.
(And thanks!)
In Learning from Rails' failuresSomeone has Sequel/Arel envy :)
https://github.com/rails/arel
https://github.com/jeremyevans/sequel
In Peewee, a lightweight python ORMLooks similar to the work going on with Rails 3. http://github.com/rails/arel
In Ambition - AR Adapter to write db queries in RubySee http://github.com/rails/arel for examples of it.
In Rails 3.0 Beta ReleaseArel, a composable relational algebra for Ruby
46 points · Open discussion