1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
rails--rails/railties/CHANGELOG.md

135 lines
4.1 KiB
Markdown
Raw Normal View History

Delayed middleware delete does not allow move operations While trying to fix #16433, we made the middleware deletions always happen at the end. While this works for the case of deleting the Rack::Runtime middleware, it makes operations like the following misbehave. ```ruby gem "bundler", "< 1.16" begin require "bundler/inline" rescue LoadError => e $stderr.puts "Bundler version 1.10 or later is required. Please update your Bundler" raise e end gemfile(true) do source "https://rubygems.org" git_source(:github) { |repo| "https://github.com/#{repo}.git" } gem "rails", github: "rails/rails" end require "action_controller/railtie" class TestApp < Rails::Application config.root = __dir__ secrets.secret_key_base = "secret_key_base" config.logger = Logger.new($stdout) Rails.logger = config.logger middleware.insert_after ActionDispatch::Session::CookieStore, ::Rails::Rack::Logger, config.log_tags middleware.delete ::Rails::Rack::Logger end require "minitest/autorun" require "rack/test" class BugTest < Minitest::Test include Rack::Test::Methods def test_returns_success get "/" assert last_response.ok? end private def app Rails.application end end ``` In the case ☝️ the ::Rails::Rack::Logger would be deleted instead of moved, because the order of middleware stack building execution will be: ```ruby [:insert, ActionDispatch::Session::CookieStore, [::Rails::Rack::Logger]] [:delete, ::Rails::Rack::Logger, [config.log_tags]] ``` This is pretty surprising and hard to reason about behaviour, unless you go spelunking into the Rails configuration code. I have a few solutions in mind and all of them have their drawbacks. 1. Introduce a `Rails::Configuration::MiddlewareStackProxy#delete!` that delays the deleted operations. This will make `#delete` to be executed in order. The drawback here is backwards incompatible behavior and a new public method. 2. Just revert to the old operations. This won't allow people to delete the `Rack::Runtime` middleware. 3. Legitimize the middleware moving with the new `#move_after` and `#move_before` methods. This does not breaks any backwards compatibility, but includes 2 new methods to the middleware stack. I have implemented `3.` in this pull request. Happy holidays! 🎄
2020-01-07 13:20:03 -05:00
* Introduce middleware move operations
With this change, you no longer need to delete and reinsert a middleware to
move it from one place to another in the stack:
```ruby
config.middleware.move_before ActionDispatch::Flash, Magical::Unicorns
```
This will move the `Magical::Unicorns` middleware before
`ActionDispatch::Flash`. You can also move it after with:
```ruby
config.middleware.move_after ActionDispatch::Flash, Magical::Unicorns
```
*Genadi Samokovarov*
* Generators that inherit from NamedBase respect `--force` option
*Josh Brody*
2017-02-27 16:55:30 -05:00
* Allow configuration of eager_load behaviour for rake environment:
config.rake_eager_load
2017-02-27 16:55:30 -05:00
Defaults to `false` as per previous behaviour.
*Thierry Joyal*
* Ensure Rails migration generator respects system-wide primary key config
When rails is configured to use a specific primary key type:
```ruby
config.generators do |g|
g.orm :active_record, primary_key_type: :uuid
end
```
Previously:
```
$ bin/rails g migration add_location_to_users location:references
```
The references line in the migration would not have `type: :uuid`.
This change causes the type to be applied appropriately.
*Louis-Michel Couture* *Dermot Haughey*
* Deprecate `Rails::DBConsole#config`
`Rails::DBConsole#config` is deprecated without replacement. Use `Rails::DBConsole.db_config.configuration_hash` instead.
*Eileen M. Uchitelle*, *John Crepezzi*
* `Rails.application.config_for` merges shared configuration deeply.
2019-12-09 01:17:29 -05:00
```yaml
# config/example.yml
shared:
foo:
bar:
baz: 1
development:
foo:
bar:
qux: 2
```
```ruby
# Previously
Rails.application.config_for(:example)[:foo][:bar] #=> { qux: 2 }
# Now
Rails.application.config_for(:example)[:foo][:bar] #=> { baz: 1, qux: 2 }
```
*Yuhei Kiriyama*
* Remove access to values in nested hashes returned by `Rails.application.config_for` via String keys.
```yaml
# config/example.yml
development:
options:
key: value
```
```ruby
Rails.application.config_for(:example).options
```
This used to return a Hash on which you could access values with String keys. This was deprecated in 6.0, and now doesn't work anymore.
*Étienne Barrié*
* Configuration files for environments (`config/environments/*.rb`) are
now able to modify `autoload_paths`, `autoload_once_paths`, and
`eager_load_paths`.
2019-12-18 02:46:48 -05:00
As a consequence, applications cannot autoload within those files. Before, they technnically could, but changes in autoloaded classes or modules had no effect anyway in the configuration because reloading does not reboot.
Ways to use application code in these files:
* Define early in the boot process a class that is not reloadable, from which the application takes configuration values that get passed to the framework.
```ruby
# In config/application.rb, for example.
require "#{Rails.root}/lib/my_app/config"
# In config/environments/development.rb, for example.
config.foo = MyApp::Config.foo
```
* If the class has to be reloadable, then wrap the configuration code in a `to_prepare` block:
```ruby
config.to_prepare do
config.foo = MyModel.foo
end
```
That assigns the latest `MyModel.foo` to `config.foo` when the application boots, and each time there is a reload. But whether that has an effect or not depends on the configuration point, since it is not uncommon for engines to read the application configuration during initialization and set their own state from them. That process happens only on boot, not on reloads, and if that is how `config.foo` worked, resetting it would have no effect in the state of the engine.
*Allen Hsu* & *Xavier Noria*
2019-11-23 19:20:00 -05:00
* Support using environment variable to set pidfile.
*Ben Thorner*
2019-04-24 15:57:14 -04:00
Please check [6-0-stable](https://github.com/rails/rails/blob/6-0-stable/railties/CHANGELOG.md) for previous changes.