| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The receiver in a scope was changed from `klass` to `relation` itself
for all scopes (named scope, default_scope, and association scope)
behaves consistently.
In addition. Before 5.2, if both an AR model class and a Relation
instance have same named methods (e.g. `arel_attribute`,
`predicate_builder`, etc), named scope doesn't respect relation instance
information.
For example:
```ruby
class Post < ActiveRecord::Base
has_many :comments1, class_name: "RecentComment1"
has_many :comments2, class_name: "RecentComment2"
end
class RecentComment1 < ActiveRecord::Base
self.table_name = "comments"
default_scope { where(arel_attribute(:created_at).gteq(2.weeks.ago)) }
end
class RecentComment2 < ActiveRecord::Base
self.table_name = "comments"
default_scope { recent_updated }
scope :recent_updated, -> { where(arel_attribute(:updated_at).gteq(2.weeks.ago)) }
end
```
If eager loading `Post.eager_load(:comments1, :comments2).to_a`,
`:comments1` (default_scope) respects aliased table name, but
`:comments2` (using named scope) may not work correctly since named
scope doesn't respect relation instance information. See also 801ccab.
But this is a breaking change between releases without deprecation.
I decided to bring back private class methods accessibility in named
scope.
Fixes #31740.
Fixes #32331.
|
|
|
|
|
|
| |
This reverts commit cf4f05a7d4a2051cf3593bc7c3a6a216e74e797a.
Since Rails 6 requires Ruby 2.4.1+.
|
|
|
|
| |
`CollectionProxy`
|
|
|
|
|
|
|
| |
It is only used `primary_key` and `connection` in the internal, so it is
not needed to delegate others to `klass` explicitly.
This doesn't change public behavior because `relation` will delegate
missing method to `klass`.
|
|\
| |
| | |
Delegate :rindex, :slice, :rotate(missing) to 'records'
|
| | |
|
|/
|
| |
Context: https://github.com/rails/rails/pull/29619#discussion_r125158589
|
| |
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| | |
kamipo/remove_method_missing_in_relation_delegation
Remove `method_missing` in `Relation::Delegation`
|
| |
| |
| |
| | |
The `method_missing` is never reached since 64c53d7c.
|
| |
| |
| |
| |
| | |
The delegation was needed since passing `relation` with
`relation.bound_attributes`. It should use `relation.arel` in that case.
|
|\ \
| | |
| | |
| | | |
Fix association with extension issues
|
| |/
| |
| |
| |
| |
| |
| |
| | |
This fixes the following issues.
* `association_scope` doesn't include `default_scope`. Should use `scope` instead.
* We can't use `method_missing` for customizing existing method.
* We can't use `relation_delegate_class` for sharing extensions. Should extend per association.
|
|/
|
|
|
|
|
|
| |
Currently `ast` and `locked` are used in the internal but delegating to
`arel` is depend on `method_missing`. If a model class is defined these
methods, `select_all` will be broken.
It should be delegated to `arel` explicitly.
|
|\
| |
| | |
Mixin `CollectionProxy::DelegateExtending` after `ClassSpecificRelation`
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`ClassSpecificRelation` has `method_missing` and the `method_missing` is
called first. if an associated class has the missing method in a
relation, never reach to the `method_missing` in the `CollectionProxy`.
I extracted `DelegateExtending` and included it to the delegate class
that including `ClassSpecificRelation` to fix the issue.
Fixes https://github.com/rails/rails/pull/28246#issuecomment-296033784.
|
|/
|
|
|
|
|
| |
Follow up of 03d3f036.
Some of `respond_to?` were replaced to `respond_to_missing?` in 03d3f036.
But the visibility is still public. It should be private.
|
|
|
|
|
|
|
| |
Since b644964b `ActiveRecord::Relation` includes `Enumerable` so
delegating `collect`, `all?`, and `include?` are also unneeded.
`collect` without block returns `Enumerable` without preloading by that.
We should use `load` rather than `collect` for force loading.
|
|
|
|
|
|
|
|
|
|
| |
This fixes CI failure due to 48f3be8c.
`Enumerable#uniq` was introduced since Ruby 2.4. We should delegate
`uniq` to `records` explicitly.
And since b644964b `ActiveRecord::Relation` includes `Enumerable` so
delegating `map` is unneeded.
|
| |
|
| |
|
| |
|
|
|
|
| |
Closes #14640
|
| |
|
| |
|
|
|
|
|
|
| |
Regexp#match? should be considered to be part of the Ruby core library. We are
emulating it for < 2.4, but not having to require the extension is part of the
illusion of the emulation.
|
|
|
|
|
|
|
|
|
|
| |
This was almost every case where we are overriding `respond_to?` in a
way that mirrors a parallel implementation of `method_missing`. There is
one remaining case in Active Model that should probably do the same
thing, but had a sufficiently strange implementation that I want to
investigate it separately.
Fixes #26333.
|
|\
| |
| | |
add more array methods to straight delegation to speed up calling them
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| |
|
|
|
|
|
| |
Where appropriatei, prefer the more concise Regexp#match?,
String#include?, String#start_with?, or String#end_with?
|
| |
|
|
|
|
|
| |
‘set’
found these commits https://github.com/rails/rails/commit/9cc8c6f3730df3d94c81a55be9ee1b7b4ffd29f6, https://github.com/rails/rails/commit/9d79334a1dee67e31222c790e231772deafcaeb8 that also should remove it.
|
|
|
|
|
|
| |
Clarifying this separation and enforcing relation immutability is the
culmination of the previous efforts to remove the mutator method
delegations.
|
|
|
|
|
|
|
|
|
|
| |
Delegation of some `Array` methods was removed in commit 9d79334. That
change did add explicit delegation of a few methods that `Array` has but
which aren't on `Enumerable`. However, a few non-mutation methods were
omitted. This adds `Array` delegation of `#in_groups`, `#in_groups_of`,
`#shuffle` and `#split`. This allows things like
`MyThing.all.in_groups_of(3) { ... }` to continue working as they did
before commit 9d79334.
|
|
|
|
|
| |
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`
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I wrote a utility that helps find areas where you could optimize your program using a frozen string instead of a string literal, it's called [let_it_go](https://github.com/schneems/let_it_go). After going through the output and adding `.freeze` I was able to eliminate the creation of 1,114 string objects on EVERY request to [codetriage](codetriage.com). How does this impact execution?
To look at memory:
```ruby
require 'get_process_mem'
mem = GetProcessMem.new
GC.start
GC.disable
1_114.times { " " }
before = mem.mb
after = mem.mb
GC.enable
puts "Diff: #{after - before} mb"
```
Creating 1,114 string objects results in `Diff: 0.03125 mb` of RAM allocated on every request. Or 1mb every 32 requests.
To look at raw speed:
```ruby
require 'benchmark/ips'
number_of_objects_reduced = 1_114
Benchmark.ips do |x|
x.report("freeze") { number_of_objects_reduced.times { " ".freeze } }
x.report("no-freeze") { number_of_objects_reduced.times { " " } }
end
```
We get the results
```
Calculating -------------------------------------
freeze 1.428k i/100ms
no-freeze 609.000 i/100ms
-------------------------------------------------
freeze 14.363k (± 8.5%) i/s - 71.400k
no-freeze 6.084k (± 8.1%) i/s - 30.450k
```
Now we can do some maths:
```ruby
ips = 6_226k # iterations / 1 second
call_time_before = 1.0 / ips # seconds per iteration
ips = 15_254 # iterations / 1 second
call_time_after = 1.0 / ips # seconds per iteration
diff = call_time_before - call_time_after
number_of_objects_reduced * diff * 100
# => 0.4530373333993266 miliseconds saved per request
```
So we're shaving off 1 second of execution time for every 220 requests.
Is this going to be an insane speed boost to any Rails app: nope. Should we merge it: yep.
p.s. If you know of a method call that doesn't modify a string input such as [String#gsub](https://github.com/schneems/let_it_go/blob/b0e2da69f0cca87ab581022baa43291cdf48638c/lib/let_it_go/core_ext/string.rb#L37) please [give me a pull request to the appropriate file](https://github.com/schneems/let_it_go/blob/b0e2da69f0cca87ab581022baa43291cdf48638c/lib/let_it_go/core_ext/string.rb#L37), or open an issue in LetItGo so we can track and freeze more strings.
Keep those strings Frozen
![](https://www.dropbox.com/s/z4dj9fdsv213r4v/let-it-go.gif?dl=1)
|
| |
|
|
|
|
|
| |
Tests should still pass after removing `require 'active_support/deprecation'`
from these files since the related deprecations have been removed.
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Fixes #14752
Select mimics the block interface of arrays, but does not mock the
block interface for select!. This change moves the api to be a
private method, _select!.
|