Since Ruby 2.7 `self.some_private_method` works fine.
So now that Ruby 2.7 is the minimal supported version,
`define_proxy_call` can always prepend `self.`
When requiring only "active_support/hash_with_indifferent_access",
calling `slice!` method on `HashWithIndifferentAccess` object
causes `NoMethodError`.
This is caused by `slice!` method calls `super` which is defined
in "active_support/core_ext/hash/slice" that' not required by this file.
Adding `require "active_support/core_ext/hash/slice"` to hwia
resolves this issue.
Note: since all tests `require_relative "abstract_unit"` that requires
"active_support/core_ext/hash/slice" eventually, it's pretty hard to
test method behavior without require.
Prior to this change, javascript_include_tag was sending a hint using
rel="preload" for all scripts, including those of type="module".
This causes the browser to make a request to preload the script, but
because the rel is incorrect, it won't be able to reuse it.
When passing type="module", it should use rel=modulepreload instead.
[0] developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content
[1] developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Link
[2] developer.mozilla.org/en-US/docs/Web/HTML/Link_types/modulepreload
While working on another branch I noticed that this `resource_id` was
set to a string. I ran all the tests for sqlite, mysql, and postgres and
none failed so I think this is an oversight. As far as I can tell this
was supposed to be an integer.
Fixes: #41453Closes: #41461
Previously when a model had strict loading set to true and then had a
relation set strict_loading to false the false wasn't considered when
deciding whether to raise/warn about strict loading.
Code example:
```ruby
class Dog < ActiveRecord::Base
self.strict_loading_by_default = true
has_many :treats, strict_loading: false
end
```
In the example, `dog.treats` would still raise even though
`strict_loading` was set to false. This is a bug effecting more than
Active Storage which is why I made this PR superceeding #41461. We need
to fix this for all applications since the behavior is a little
surprising. I took the test from ##41461 and the code suggestion from #41453
with some additions.
Co-authored-by: Radamés Roriz <radamesroriz@gmail.com>
This class represents the query a Preloader::Association uses to load
its records. This replaces the previous concept of a grouping_key and
serves both to group Preloader::Associations by their query and to run
the query to load the records (which nicely avoids using .first).
This should not change any functionality but should be slightly faster
due to being able to avoid calling `scope.to_sql` unless necessary.
This allows running either load_records or fetch_from_preloaded_records
depending on whether associations are already loaded. This allows
calling preloaded_records without necessarily having called run first.
Co-authored-by: Dinah Shi <dinahshi@github.com>
`TreeManager` is inherited by `InsertManager` but `where` on
`InsertManager` doesn't work.
And also, remove `@ctx` since the instance variable is used only for the
`SelectManager`.
I used `type.cast(value)` to emulate unchecked serialized value in
`unboundable?`, since `RangeError` was raised only for the integer type,
so the emulation works enough for the integer type.
But since #41516, Enum types are also not always serializable, so
`type.cast(value)` may also be called for the enum types.
I've delegated `type.cast(value)` to the subtype if an unknown label is
passed to work the emulation even on Enum types in 3b6461b. But it is
strange to delegate to the subtype for the emulation only if an unknown
label is passed.
Instead of using `type.cast(value)` for the emulation, extend
`serializable?` to get unchecked serialized value if the value is not
serializable.
Test case which was added at #32852 passes in Active Model but doesn't
pass in Active Record since #38210 due to `Float::DIG` has changed to
`BigDecimal.double_fig`.
```ruby
irb(main):001:0> require 'bigdecimal/util'
=> true
irb(main):002:0> 65.6.to_d
=> 0.656e2
irb(main):003:0> 65.6.to_d(Float::DIG)
=> 0.656e2
irb(main):004:0> 65.6.to_d(BigDecimal.double_fig)
=> 0.6559999999999999e2
```
The policy for security patches is very strict, and some people may find it surprising that even breaking changes as a result of an oversight or bug in a security fix will neither receive a release of their own nor be included in any subsequent security patches to address other security issues. Hopefully this additional text will help clarify this and avoid confusion.
https://github.com/rails/rails/issues/41653 noted an issue where if there's service configured (`config.active_storage.service` is commented out), Blob creation via direct upload crashes:
```
Started POST "/rails/active_storage/direct_uploads" for ::1 at 2021-03-09 13:02:57 -0800
Processing by ActiveStorage::DirectUploadsController#create as JSON
Parameters: {"blob"=>{"filename"=>"banana.jpg", "content_type"=>"image/jpeg", "byte_size"=>577085, "checksum"=>"W/vo/JqBNmJHMCaL+PRlBQ=="}, "direct_upload"=>{"blob"=>{"filename"=>"banana.jpg", "content_type"=>"image/jpeg", "byte_size"=>577085, "checksum"=>"W/vo/JqBNmJHMCaL+PRlBQ=="}}}
Completed 500 Internal Server Error in 12ms (ActiveRecord: 3.3ms | Allocations: 5864)
NoMethodError (undefined method `name' for nil:NilClass):
activestorage (6.1.3) app/models/active_storage/blob.rb:52:in `block in <class:Blob>'
activesupport (6.1.3) lib/active_support/callbacks.rb:427:in `instance_exec'
```
This PR fixes that crash. Blob creation will still fail, but with a more informative error about a `service_name` being required.
