| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes:
1.second.eql?(1.second) #=> false
The new `eql?` requires that `other` is an `ActiveSupport::Duration`.
This requirement makes `ActiveSupport::Duration`'s behavior consistent
with other numeric types in Ruby.
1.eql?(1.0) #=> false
1.0.eql?(1) #=> false
1.second.eql?(1) #=> false (was true)
1.eql?(1.second) #=> false
{ 1 => "foo", 1.0 => "bar" }
#=> { 1 => "foo", 1.0 => "bar" }
{ 1 => "foo", 1.second => "bar" }
# now => { 1 => "foo", 1.second => "bar" }
# was => { 1 => "bar" }
And though the behavior here hasn't changed, for reference:
1 == 1.0 #=> true
1.0 == 1 #=> true
1 == 1.second #=> true
1.second == 1 #=> true
|
|\
| |
| | |
Active support instead of ActiveSupport::Deprecation.silence we can use assert_deprecated
|
| |
| |
| |
| | |
assert_deprecated
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It was causing error when using `with_options` passing a lambda as its
last argument.
class User < ActiveRecord::Base
with_options dependent: :destroy do |assoc|
assoc.has_many :profiles, -> { where(active: true) }
end
end
It was happening because the `option_merger` was taking the last
argument and checking if it was a Hash. This breaks the HasMany usage,
because its last argument can be a Hash or a Proc.
As the behavior described in this test:
https://github.com/rails/rails/blob/master/activesupport/test/option_merger_test.rb#L69
the method will only accept the lambda, this way it will keep the expected behavior. See 9eaa0a34
|
| |
| |
| |
| |
| | |
Change to require all active_support/deprecation since that's the actual
entry point for the deprecation methods.
|
| | |
|
| | |
|
|/
|
|
|
|
|
| |
Make `#prepend` method modify instance in-place and return self
instead of just returning modified value. That is exactly what
`#prepend!` method was doing previously, so it's deprecated from
now on.
|
|
|
|
|
|
| |
In particular, `.new`, `#update`, `#merge`, `#replace` all accept
objects which respond to `#to_hash`, even if those objects are not
Hashes directly.
|
|
|
|
| |
actually doesn't increment/decrement in localstore.
|
| |
|
|
|
|
|
|
|
| |
Closes #14405.
This is a follow-up to 9e997e9039435617b6a844158f5437e97f6bc107 to restore
the documented behavior.
|
|
|
|
|
| |
Conflicts:
activesupport/lib/active_support/core_ext/hash/conversions.rb
|
|
|
|
| |
requires. Appropriate to keep this, users don't care that the implementation got unified.
|
| |
|
|
|
|
|
|
| |
Apparently we've been using a buggy feature for the past 6 years:
https://bugs.ruby-lang.org/issues/9593
|
| |
|
|\
| |
| | |
Fix OrderedHash.select to return self instance.
|
| |
| |
| |
| |
| |
| | |
On ruby 2.1.1 the behavior of .select and .reject has changed.
They will return a Hash new instance, so we need to override them to
keep the instance object class.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This method return `Gem::Version.new(Rails.version)`, suggesting a more
reliable way to perform version comparison.
Example:
Rails.version #=> "4.1.2"
Rails.gem_version #=> #<Gem::Version "4.1.2">
Rails.version > "4.1.10" #=> false
Rails.gem_version > Gem::Version.new("4.1.10") #=> true
Gem::Requirement.new("~> 4.1.2") =~ Rails.gem_version #=> true
This was originally introduced as `.version` by @charliesome in #8501
but got reverted in #10002 since it was not backward compatible.
Also, updating template for `rake update_versions`.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 475c96589ca65282e1a61350271c2f83f0d4044f, reversing
changes made to 705915ab5cf24430892107764b0050c07e1df583.
We decided that this is not worth busting everyone's cache as this
seems like a very unlikely problem. The problem only occurs when the
user is 1) not using a namespace, or 2) using the same namesapce for
different *kinds* of cache items. The recommended "fix" is to put
those cache items into their own namspace:
id = 1
Rails.cache.fetch(id, namespace: "user"){ User.find(id) }
ids = [1]
Rails.cache.fetch(ids, namespace: "users"){ User.find(ids) }
See the discussion on #14269 for details.
|
| |
| |
| |
| |
| |
| |
| |
| | |
`cache.fetch(['foo'])` and `cache.fetch('foo')` should generate
different cache keys as they are not equivalents.
[related #8615]
[related #8614]
|
|/
|
|
|
|
| |
The 'cow' => 'kine' inflection has gone with c300dca9 but it should
not be removed from the tested irregularities since it ensures that
inflections work with words that do not begin with the same letters.
|
|
|
|
|
|
|
| |
The current implementation of `fetch_multi` returns an array and has no
means to easily backtrack which names yielded which results. By changing
the return value to a Hash we retain the name information. Hash#values
can be used on the response if only the values are needed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Benchmark:
Benchmark.ips do |x|
x.report("home") { "home".underscore }
x.report("Home") { "Home".underscore }
x.report("homeBase") { "homeBase".underscore }
x.report("home::base") { "home::base".underscore }
end
Before:
Calculating -------------------------------------
home 2598 i/100ms
Home 2463 i/100ms
homeBase 2300 i/100ms
home::base 2086 i/100ms
-------------------------------------------------
home 28522.3 (±14.7%) i/s - 140292 in 5.065102s
Home 29165.8 (±14.9%) i/s - 140391 in 5.000475s
homeBase 26218.5 (±7.1%) i/s - 131100 in 5.030485s
home::base 27712.3 (±5.9%) i/s - 139762 in 5.064077s
After:
Calculating -------------------------------------
home 23163 i/100ms
Home 2432 i/100ms
homeBase 2160 i/100ms
home::base 2265 i/100ms
-------------------------------------------------
home 1501614.8 (±10.2%) i/s - 7412160 in 5.009540s
Home 28754.0 (±8.5%) i/s - 143488 in 5.033886s
homeBase 25331.1 (±5.6%) i/s - 127440 in 5.047940s
home::base 27089.9 (±5.5%) i/s - 135900 in 5.033516s
|
|
|
|
| |
Remove 4-1 related entries from master [ci skip]
|
|
|
|
| |
good, but the closer relationship to #presence over #present is ultimately worth it
|
|\
| |
| | |
Extract local cache middleware
|
| |
| |
| |
| |
| | |
Extract LocalCache Middleware, so it can requires rack dependencies,
without adding rack dependencies to `AS::Cache::Strategy::LocalCache`.
|
|/ |
|
| |
|
|\
| |
| | |
Add note to silence_stream and quietly. [skip ci]
|
| |
| |
| |
| |
| |
| | |
State that on the doc.
[fixes #11954]
|
|\ \
| | |
| | |
| | |
| | |
| | | |
Conflicts:
actionview/CHANGELOG.md
activerecord/CHANGELOG.md
|
| | | |
|
| | | |
|
| | | |
|
| |/
|/| |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Rails applications are expected to be always aware of the application
time zone.
To be consistent with that contract, we have to assume that a bare
date passed to time helpers is a date in the application time zone,
not in the system time zone. The system time zone is irrelevant, we
should totally ignore it.
For example,
travel_to user.birth_date + 40.years
should make that user be 40th years old regardless of the system
time zone. Without this patch that may not be true.
|
| |
| |
| |
| |
| |
| |
| | |
This is a follow up to: https://github.com/rails/rails/commit/07c70245a128cfe42f134be8759963dc98f1a63e
As suggested by @fxn this comment should not be visible in the API:
https://github.com/rails/rails/commit/07c70245a128cfe42f134be8759963dc98f1a63e#commitcomment-5331658
|
| |
| |
| |
| |
| | |
The previous implementation was broken because JRuby (1.7.10) doesn't
have a code converter for UTF-8 to UTF8-MAC.
|
| |
| |
| |
| | |
Closes #13993.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
guides/source/active_record_validations.md
guides/source/api_documentation_guidelines.md
guides/source/configuring.md
|
| | |
| | |
| | |
| | | |
kind of exception we should expect for this internal comment.
|
| | | |
|
| | |
| | |
| | |
| | | |
Decouple the code from the particular Ruby version.
|