When is use a scaffold_controller add the routes as resources to the
config/route.rb
Also enable to use --skip-routes if doesn't want include the resources
into the config/routes.rb file.
The schema cache tests test the following scenarios:
1) The default case works (single db, primary spec name (dev is default
to primary in 2-tier config), standard default schema cache filename)
2) Primary always wins over other entries
3) A custom schema cache filename works when set in the configuration
4) A custom schema cache filename works when set in the ENV
Cases that don't work:
1) A non-primary database entry picks up a namespaced schema cache file
This can't work currently because there's no way of knowing which cache
we actually want. In this railtie we can only load ActiveRecord::Base's
schema cache. If we grab the first config we risk loading a cache for
another connection because order is not guaranteed.
2) Multi-db schema caches
The reasons are similar to above. In addition we can't loop through the
configs, establish a connection, and load the cache because we don't
know what parent class to establish a connection to. In that case AR
Base will always get the cache and it would cause the last one to win
and therefore be loaded on the wrong connection.
The real fix for these issues is to get rid of the railtie entirely, but
for now we needed to set this back to what the behavior was before
recent changes but with the ability to pass a custom key.
Co-authored-by: Katrina Owen <kytrinyx@github.com>
When generating applications, it initializes Git repository since
8989a5057b
However, it doesn't initialize Git when creating plugins.
Plugins are mostly libraries and are likely hosted on GitHub,
so initializing Git for plugins makes sense.
The initializer that loads the default schema cache on the default
connection doesn't account for the case where an app overrides the
default filename either via ENV["SCHEMA_PATH"], or via the
:schema_cache_path defined in the db config.
Note that as discussed in #34449 this initializer doesn't work for
applications using multiple databases, and this change doesn't fix that.
Introduce benchmark generator to add benchmarks to Rails applications.
The generator makes use of `benchmark-ips`, and will automatically add
the gem to the Gemfile as needed.
Co-authored-by: Gannon McGibbon <gannon.mcgibbon@gmail.com>
When generating a new app without `--skip-spring`, caching classes was
disabled in `environments/test.rb`. This was implicitly disabling caching
view templates too. This change will enable view template caching by adding
this to the generated `environments/test.rb`:
config.action_view.cache_template_loading = true
See 65344f254cde87950c7f176cb7aa09c002a6f882
Database configurations are now objects almost everywhere, so we don't
need to fake access to a hash with `#default_hash` or it's alias `#[]`.
Applications should `configs_for` and pass `env_name` and `spec_name` to
get the database config object. If you're looking for the default for
the test environment you can pass `configs_for(env_name: "test", spec_name:
"primary")`. Change test to developement to get the dev config, etc.
`#default_hash` and `#[]` will be removed in 6.2.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
This change addresses a few issues:
First, shelling out to the `rails` command requires the destination
directory to contain certain files that the command uses to initialize
itself. While this is not an issue when running generators normally, it
is troublesome when testing generator-invoking generators which output
to ephemeral destination directories.
Second, shelling out to the `rails` command is very slow. This also is
not a particular concern when running generators normally, but it makes
test suites for generator-invoking generators painfully slow.
Third, shelling out to the `rails` command fails silently by default.
Such silent failures can be surprising, and can lead to confusing
downstream failures.
The Gemfile offers more flexibility than the gemspec in terms of gem
groups and platforms. Putting the default development dependencies in
the Gemfile encourages users to add their own development dependencies
to the Gemfile. This is similar to the current behavior of the
`bundle gem` command (see bundler/bundler#7222).
This change also fixes a corner case where using the "--skip-gemspec"
and "--skip-active-record" options together would incorrectly generate a
"sqlite3" dependency in the Gemfile.
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! 🎄
The main interface to eager loading is config.eager_load. The logic that
implies happens during the boot process.
With the introduction of Zeitwerk, application code is loaded in the
finisher as everything else, but in previous versions of Rails users
could eager load the application code regardless of config.eager_load.
Use cases:
* Some gems like indexers need to have everything in memory and would
be a bad user experience to ask users to conditionally set the eager
load flag.
* Some tests may need to have everything in memory and would be a bad
experience to have the flag enabled globally in the test environment.
I personally feel that the contract between this method and the entire
eager loading process is ill-defined. I believe this method is
essentially internal. The purpose of this patch is simply to restore this
functionality emulating what it did before because rethinking the design
of this interface may need time.
Fixes https://github.com/rails/rails/issues/28827.
The steps to reproduce are as follows:
git clone git@github.com:bbuchalter/rails-issue-28827.git
cd rails-issue-28827
bundle install
bin/rails db:create
Observe that we create two databases when invoking db:create: development and test. Now observe what happens when we invoke our drop command while using DATABASE_URL.
DATABASE_URL=sqlite3://$(pwd)/db/database_url.sqlite3 bin/rails db:create
As expected, the development environment now uses the DATABASE_URL. What is unexpected is that the test environment does not.
It's unclear what the expected behavior should be in this case, but the cause of it is this: 9f2c74eda0/activerecord/lib/active_record/tasks/database_tasks.rb (L494)
Because of each_local_configuration, there seems to be no way invoke these database rake on only the development environment to ensure DATABASE_URL is respected.
The smallest scope of change I can think to make would be to conditionalize this behavior so it does not get applied when DATABASE_URL is present.
Rails::Configuration::Generators provides method_missing based accessor.
The following code sets `orm` value:
Rails.application.config.generators.orm :data_mapper
The following code does NOT return `orm` value:
Rails.application.config.generators.orm # => {}
It's better that the reader returns the value set by writter in terms of
consistency:
Rails.application.config.generators.orm # => :data_mapper
- ### Problem
ActionPack requires "action_view/base" at boot time, this
causes a variety of issue that I described in detail in #38024.
There is no real reason to require av/base in the
ActionDispatch::Debugexceptions class.
### Solution
Like any other components (such as ActiveRecord, ActiveJob...),
ActionView::Base shouldn't be loaded at boot time.
Here are the two main changes needed for this:
1) Actionview has a special initializer that needs to run
before the app is fully booted (adding a executor needs to be done
before application is done booting)
63ec70e700/actionview/lib/action_view/railtie.rb (L81-L84)
That initializer used a lazy load hooks but we can't do that anymore
because Action::Base view won't be triggered during booting process.
When it will get triggered, (presumably on the first request),
it's too late to add an executor.
------------------------------------------------
2) Compare to other components, ActionView doesn't use `Base` for
configuration flag. A lot of flags ares instead set on modules
(FormHelper, FormTagHelper).
The problem is that those module depends on AV::Base to be
loaded, as otherwise configuration set by the user aren't applied.
(Since the lazy load hooks hasn't been triggered)
63ec70e700/actionview/lib/action_view/railtie.rb (L66-L69)
We shouldn't wait for AB::Base to be loaded in order to set these
configuration. However, we need to do it inside an
`after_initialize` block in order to let application
set it to the value they want.
Closes#28538
Co-authored-by: betesh <iybetesh@gmail.com>"
We missed these in rails/rails#38005 because deprecation warnings are
silently swallowed by these tests.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
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.
Co-authored-by: Dermot Haughey <hderms@gmail.com>
Enabling `SameSite` cookie protection is an addition to CSRF protection,
where cookies won't be sent by browsers in cross-site POST requests when set to `:lax`.
`:strict` disables cookies being sent in cross-site GET or POST requests.
Passing `:none` disables this protection and is the same as previous versions albeit a `; SameSite=None` is appended to the cookie.
See upgrade instructions in config/initializers/new_framework_defaults_6_1.rb.
More info [here](https://tools.ietf.org/html/draft-west-first-party-cookies-07)
_NB: Technically already possible as Rack supports SameSite protection, this is to ensure it's applied to all cookies_
This change deprecates config in dbconsole and updates usage in the
dbconsole tests so that we can remove an accessor on the
`configuration_hash`.
Eventually we want to pass objects around everywhere instead of
hashes. Callers can use `db_config` to access the hash if necessary.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
