| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| |
| |
| | |
Conflicts:
activerecord/CHANGELOG.md
activesupport/CHANGELOG.md
|
| |\
| | |
| | | |
Active support callback's before/after/around filters are not correctly making their singleton methods private
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Auto-generate stable fixture UUIDs on PostgreSQL
Conflicts:
activerecord/CHANGELOG.md
activerecord/lib/active_record/fixtures.rb
activerecord/test/cases/adapters/postgresql/uuid_test.rb
activesupport/CHANGELOG.md
|
| | |
| | |
| | |
| | | |
Fixes: #11524
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 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
|
| | |
| | |
| | |
| | | |
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.
|
| | | | |
| | | | |
| | | | |
| | | | | |
unexpected circular dependency error
|
| | | | | |
|