rails--rails/railties/CHANGELOG.md at e7c3eb11e05236c22475ff391303bcfb80cf4fbe

kotovalexarian-likes-github/rails--rails

mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00

Genadi Samokovarov 40fc1651ad 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-08 11:30:02 +02:00

4.1 KiB

Raw Blame History

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:
```
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:
```
config.middleware.move_after ActionDispatch::Flash, Magical::Unicorns
```
Genadi Samokovarov
Generators that inherit from NamedBase respect --force option

Josh Brody
Allow configuration of eager_load behaviour for rake environment:
```
config.rake_eager_load
```
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:
```
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.

# config/example.yml
shared:
  foo:
    bar:
      baz: 1
development:
  foo:
    bar:
      qux: 2

# 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.
```
# config/example.yml
development:
  options:
    key: value
```
```
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.

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.
```
# 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:
```
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
Support using environment variable to set pidfile.

Ben Thorner

Please check 6-0-stable for previous changes.

4.1 KiB Raw Blame History

4.1 KiB

Raw Blame History