| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
skip]
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
prevent mass assignment of polymorphic type when using `build`
Conflicts:
activerecord/CHANGELOG.md
|
| | |
| |
| |
| | |
Closes #8265
|
| | |
| |
| |
| |
| |
| |
| | |
Since edd94cee9af1688dd036fc58fd405adb30a5e0da, CollectionProxy
delegates all calculation methods - except count - to the scope,
which does basically what this method was doing, but since we're
delegating from the proxy, the association method was never called.
|
| | |
| |
| |
| |
| |
| |
| | |
To perform a sum calculation over the array of elements, use to_a.sum(&block).
Please check the discussion in f9cb645dfcb5cc89f59d2f8b58a019486c828c73
for more context.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit f9cb645dfcb5cc89f59d2f8b58a019486c828c73.
Conflicts:
activerecord/CHANGELOG.md
Revert "Allow blocks for count with ActiveRecord::Relation. Document and test that sum allows blocks"
This reverts commit 9cc2bf69ce296b7351dc612a8366193390a305f3.
Conflicts:
activerecord/lib/active_record/relation/calculations.rb
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This improves memory and performance without having to use symbols which
present DoS problems. Thanks @headius and @tenderlove for the
suggestion.
This was originally committed in
f1765019ce9b6292f2264b4601dad5daaffe3a89, and then reverted in
d3494903719682abc0948bef290af0d3d7b5a440 due to it causing problems in a
real application. This second attempt should solve that.
Benchmark
---------
require 'active_record'
require 'benchmark/ips'
ActiveRecord::Base.establish_connection(adapter: 'sqlite3', database: ':memory:')
class Post < ActiveRecord::Base
connection.create_table :posts, force: true do |t|
t.string :name
end
end
post = Post.create name: 'omg'
Benchmark.ips do |r|
r.report('Post.new') { Post.new name: 'omg' }
r.report('post.name') { post.name }
r.report('post.name=') { post.name = 'omg' }
r.report('Post.find(1).name') { Post.find(1).name }
end
Before
------
Calculating -------------------------------------
Post.new 1419 i/100ms
post.name 7538 i/100ms
post.name= 3024 i/100ms
Post.find(1).name 243 i/100ms
-------------------------------------------------
Post.new 20637.6 (±12.7%) i/s - 102168 in 5.039578s
post.name 1167897.7 (±18.2%) i/s - 5186144 in 4.983077s
post.name= 64305.6 (±9.6%) i/s - 317520 in 4.998720s
Post.find(1).name 2678.8 (±10.8%) i/s - 13365 in 5.051265s
After
-----
Calculating -------------------------------------
Post.new 1431 i/100ms
post.name 7790 i/100ms
post.name= 3181 i/100ms
Post.find(1).name 245 i/100ms
-------------------------------------------------
Post.new 21308.8 (±12.2%) i/s - 105894 in 5.053879s
post.name 1534103.8 (±2.1%) i/s - 7634200 in 4.979405s
post.name= 67441.0 (±7.5%) i/s - 337186 in 5.037871s
Post.find(1).name 2681.9 (±10.6%) i/s - 13475 in 5.084511s
|
| |\
| |
| | |
Coerce strings in create_join_table.
|
| | |
| |
| |
| |
| |
| |
| | |
If you accidentally pass a string and a symbol, this breaks. So
we coerce them both to strings.
Fixes #7715
|
| | | |
|
| |\ \
| | |
| | | |
Postgresql adapter: fix handling of BC timestamps
|
| | | | |
|
| |/ / |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
AR::Base.becomes should not change the STI type
Conflicts:
activerecord/CHANGELOG.md
|
| | | |
| | |
| | |
| | | |
If you want to change the STI type too, use AR::Base.becomes! instead
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ / |
|
| | |
| |
| | |
The `ActiveRecord::Fixtures::find_table_name` method was removed from "master" almost a year ago, but it was never deprecated. Here it comes back, more dead than alive.
|
| |\ \
| | |
| | |
| | |
| | | |
Conflicts:
actionpack/lib/action_dispatch/routing/redirection.rb
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
`#pluck` can be used on a relation with `select` clause (#7551)
|
| | | | |
| | | |
| | | |
| | | | |
Closes #7551
|
| |/ / / |
|
| | | |
| | |
| | |
| | |
| | | |
Thanks @toretore.
https://github.com/rails/rails/commit/9e4c41c903e8e58721f2c41776a8c60ddba7a0a9#commitcomment-2134706
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Two threads may be in method_missing at the same time. If so, they might
both try to define the same delegator method.
Such a situation probably wouldn't result in a particularly spectacular
bug as one method would probably just be overridden by an identical
method, but it could cause warnings to pop up. (It could be worse if
method definition is non-atomic in a particular implementation.)
(We will also need this mutex shortly anyway, see #8127.)
|
| | | | |
|
| | | |
| | |
| | |
| | | |
We should not need any `serialized_attributes` checks outside `ActiveRecord::AttributeMethods::Serialization` module.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Most apps upgrading from 3.x will have options for mass assigment in
their application.rb and environments/*.rb config files. Rather than
just raising a NoMethodError when copying the config, this commit
adds a warning message until either the protected_attributes gem
is installed or the relevant config options are removed.
|
| | | |
| | |
| | |
| | |
| | | |
These were removed with ActiveRecord::Model in
https://github.com/rails/rails/commit/9e4c41c903e8e58721f2c41776a8c60ddba7a0a9#L15L156
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Rather than just changing it and hoping for the best.
Requested by @jeremy:
https://github.com/rails/rails/commit/ba1544d71628abff2777c9c514142d7e9a159111#commitcomment-2106059
|
| |\ \ \
| | | |
| | | | |
:counter_cache option for to support custom named counter caches
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
So that the scope may be a NullRelation and return a result without
executing a query.
Fixes #7928
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fixes #8102.
I couldn't find a nicer way to deal with this than delegate the call to
#scope, which will be a NullRelation when we want it to be.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This allows us to avoid hacks like the "return 0 if owner.new_record?"
in #count (which this commit removes).
Also, the relevant foreign key may actually be present even on a new
owner record, in which case we *don't* want a null relation. This logic
is encapsulated in the #null_scope? method.
We also need to make sure that the CollectionProxy is not 'infected'
with the NullRelation module, or else the methods from there will
override the definitions in CollectionProxy, leading to incorrect
results. Hence the nullify: false option to CollectionAssociation#scope.
(This feels a bit nasty but I can't think of a better way.)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
null relations
For example, the following should not run any query on the database:
Post.new.comments.where(body: 'omg').to_a # => []
Fixes #5215.
|
