What?
From now on when `accepts_nested_attributes_for` defined and `extend` option
added the overwritten `build` method being called.
[Alireza Bashiri, Martins Polakovs]
Going one level downwards from Rails' /public directory would still be inside the public directory and therefore servable by the web server. Files should stored upwards of the public directory.
This reverts commit d162188dd662a7d9f62ba8431474f50bc35e3e93, reversing
changes made to 3576782888c307e3e192c44e332b957cd1174128.
Reason: #24131 conflicts the #5153's default order contract, it means
that existing apps would be broken by that change.
We don't want to break existing apps without a deprecation cycle.
Since 9ac7dd4, class level `update`, `destroy`, and `delete` were placed
in the `Persistence` module as class methods.
But `Relation#update` without passing ids which was introduced at #11898
is not a class method, and it was caused the extra scoping regression
#33470.
I moved the relation method back into the `Relation` to fix the
regression.
Fixes#33470.
Nesting respond_to calls can lead to unexpected behavior, so it should be
avoided. Currently, the first respond_to format match sets the content-type
for the resulting response. But, if a nested respond_to occurs, it is possible
to match on a different format. For example:
respond_to do |outer_type|
outer_type.js do
respond_to do |inner_type|
inner_type.html { render body: "HTML" }
end
end
end
Browsers will often include */* in their Accept headers. In the above example,
such a request would result in the outer_type.js match setting the content-
type of the response to text/javascript, while the inner_type.html match will
cause the actual response to return "HTML".
This change tries to minimize potential breakage by only raising an exception
if the nested respond_to calls are in conflict with each other. So, something
like the following example would not raise an exception:
respond_to do |outer_type|
outer_type.js do
respond_to do |inner_type|
inner_type.js { render body: "JS" }
end
end
end
While the above is nested, it doesn't affect the content-type of the response.
- Refactoring alias_chain to Module#prepend broke the possibility to deprecate class methods since the module
generated was prepended to the target's instance.
A suggestion to fix this was to use `AS#redefine_method` which would solve the
problem but with the cost of redefining directly the method.
Decided to go with the same alias_chain implementation as before instead.
- Fixes#33253
According to #33449 and #33468, cpu_time and allocations are 0 when
JRuby is used.
```ruby
$ ruby -v
jruby 9.2.1.0-SNAPSHOT (2.5.0) 2018-07-27 13b2df5 Java HotSpot(TM) 64-Bit Server VM 25.181-b13 on 1.8.0_181-b13 [linux-x86_64]
$ bundle exec ruby -w -Itest test/log_subscriber_test.rb -n test_event_attributes
Run options: -n test_event_attributes --seed 6231
F
Failure:
SyncLogSubscriberTest#test_event_attributes [test/log_subscriber_test.rb:84]:
Expected 0 to be > 0.
rails test test/log_subscriber_test.rb:78
Finished in 0.018983s, 52.6791 runs/s, 105.3582 assertions/s.
1 runs, 2 assertions, 1 failures, 0 errors, 0 skips
```
The target object for counter cache is not always determined by the
primary key value on the model. I'd like to extract `update_couters`
onto the `Relation` for the internal use.