| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
| |
Context: https://github.com/rails/rails/pull/29619#discussion_r125158589
|
| |
|
|
|
|
| |
`bind_values` was removed from Arel
|
| |
|
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Active Record doesn't rely delegating to `arel` in the internal since
425f2ca. The delegation is a lower priority than delegating to `klass`,
so it is pretty unclear which method is delegated to `arel`.
For example, `bind_values` method was removed at b06f64c (a series of
changes https://github.com/rails/rails/compare/79f71d3...b06f64c). But a
relation still could respond to the method because `arel` also have the
same named method (#28976).
Removing the delegation will achieve predictable behavior.
|
|
|
|
| |
`DelegationTest#call_method` is no longer used since 9d79334a.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
| |
It appears that I missed this one when I delegated all the non-mutation
array methods that were not on Enumerable
|
|
|
|
|
|
|
|
|
| |
As was pointed out by #17128, our blacklist of mutation methods was
non-exhaustive (and would need to be kept up to date with each new
version of Ruby). Now that `Relation` includes `Enumerable`, the number
of methods that we actually need to delegate are pretty small. As such,
we can change to explicitly delegating the few non-mutation related
methods that `Array` has which aren't on `Enumerable`
|
| |
|
|
|
|
|
|
|
|
| |
This is a regression 4.0 -> 4.1 fix.
In 4.1.0 Relation#join is delegated to Arel#SelectManager.
In 4.0 series it is delegated to Array#join
This patch puts back the behaviour of 4.0
|
|
|
|
|
|
|
|
| |
This change was necessary because the whitelist wouldn't work.
It would be painful for users trying to update their applications.
This blacklist intent to prevent odd bugs and confusion in code that call mutator
methods directely on the `Relation`.
|
|
|
|
| |
won't last - aim to switch back to a blacklist for mutator methods.
|
| |
|
| |
|
| |
|
|
|
|
| |
addresses "ArgumentError: comparison of VerySpecialComment with SpecialComment failed" in ActiveRecord::DelegationRelationTest#test_#sort!_delegation_is_deprecated
|
|
|
|
| |
Without this, some tests here were not actually testing anything.
|
|
|
|
| |
[ci skip]
|
|
|
|
|
|
|
|
| |
Every method from MRI's core classes is written in C. This means
Method#arity always returns -1 for methods with a variable number of
arguments. This is not the case with Rubinius, where, for example
Array#slice! is implemented in Ruby and has arity -2, since is
defined as def slice!(start, length = undefined)
|
|
The primary means of returning results for Array bang methods is to modify
the array in-place. When you call these methods on a relation, that
array is created, modified, and then thrown away. Only the secondary
return value is exposed to the caller.
Removing this delegation is a straight-forward way to reduce user error
by forcing callers to first explicitly call #to_a in order to expose
the array to be acted on by the bang method.
|