We've been bumping Arel in lockstep with AR for some time now: every Rails release requires a new Arel release, and Arel releases occur specifically for Rails releases.
We're not gaining any maintenance freedom by keeping it as a separate gem, while we are paying the costs of coordination.
Scrolling through https://rubygems.org/gems/arel/reverse_dependencies shows few notable downstreams that aren't also depending on Active Record, so this change doesn't force new dependencies onto the ecosystem at large. We'll release a new version of the
We have no plans to rename the top level
The goal of these methods should be to generate in nodes, not handle every possible permutation of more than one value. The `#between` and `#not_between` methods have been extracted, which better represent the semantics of handling ranges in SQL.
It's not quite duck typed, but it will allow us to pass in our own objects with additional logic (like type casting).
We know the API for the depth first visitor in advance, so it's OK to calcuate this cache in advance
This removes the need for us to do the re-ordering by walking the AST in ActiveRecord. We're using a block to communicate with the collector, since the collector needs to be the thing which knows about the index, while the visitor is the thing that needs to know the syntax. The BindParam needs to know about neither of these things, so it's been changed to stop being a subclass of SqlLiteral I could also see an alternative implementation using format strings if for some reason blocks cause a problem.
The only reason we're using strings is to pre-populate the cache, but `Class#name` returns a new string instance on every call. This is a pretty major source of memory usage. We don't technically need to pre-populate the cache, and not doing so allows us to go back to using cache objects
The only place this method was still used is on the MSSQL visitor. The visitor has all of the objects required to inline this lookup there. Since the `primary_key` method on the connection adapter will perform a query when called, we can cache the result on the visitor.
It is never used outside of convenience methods which are only used in tests. In practice, it just made constructing tables more complicated on the rails side. This is the minimum possible change to remove the constructor argument, but continue to have the tests passing. I'm not sure if we have a reason to keep `project` and friends, and the solution might actually just be to remove the engine from `SelectManager` and friends. As such I've held off on deleting those methods. We need to figure out what to do with `Table#from`. It's old invocation, which read `table.from(table)` was certainly nonsensical.
We're going to start working on removing type casting from arel. To avoid doing one gigantic commit which moves everything over to eager casting, we need a way to tell Arel that we've already cast it. The easiest path to that is to give it a quoted node, and then we remove this case once we're never returning a Casted node
We need to be able to not care which we've gotten in ActiveRecord
This commit will help me a lot because when some
As a 3rd party database adapter maintainer, I'd like to know if if there is a plan to separate visitors for non bundled database adapters, such as
Actually, I'd like Arel will have these visitors at least for Rails 6, Just wanted to prepare if there is a plan.
@yahonda in the short term, we'll keep the visitors in place, despite the inconsistency.
Looking forward, I'd like to rebalance some responsibilities between the Arel and AR parts, and at that time I expect we'll try to move them closer together. But no concrete plans for now.